[Nsi-wg] Fwd: Re: Capturing AA discussion

Tue May 10 16:58:29 CDT 2011

I have attached some suggestions for specifying message authentication
and authorization of resources in the NIS documents and SC schema. This
document is the result of a  meeting held last Tues and Wednesday with
Inder Monga, Jerry Sobieski, Josva Kleist, Chin Guok, Evangelos
Chaniotakis, Eric Lomax, Andy Lake and Mary Thompson. I have also
included the highlights of the discussion that has taken place in email.

As I have a background in distributed and grid AA issues, Inder asked me
to suggest a possible attribute profile that could be adopted in the
near future. I went a bit further and addressed the issue of message
security as  well. The attached document is for discussion and suggests
alternatives and possibilities. I think the decision of what to do needs
to be made by the group as a whole making the best guess they can as to
what level of security the service providers will require and the users
will be able to comply with.

Mary Thompson

Note: I am not on the nsi-wg mailing list, so cc me on anything you want
me to read.

-------- Original Message --------
Return-Path: <mrthompson at lbl.gov>
Date: Tue, 10 May 2011 12:10:11 -0700
From: Mary Thompson <mrthompson at lbl.gov>

To: John MacAuley <john.macauley at surfnet.nl>
CC: Inder Monga <imonga at es.net>, Jerry Sobieski <jerry at sobieski.net>,
     Chin Guok <chin at es.net>, Evangelos Chaniotakis <haniotak at es.net>,
      "Eric lomax at es.net" <lomax at es.net>, kleist at nordu.net,        Andy
Lake <andy at es.net>, Mary R Thompson <MRThompson at lbl.gov>
Subject: Re: Capturing AA discussion

In response to Inder's comment: Any "security profile" is going to have
to specify the how message security is handled as well as how it
supports authorization. I agree that they are two distinct topics, but
both need to be covered.

I notice that the framework document states that it is a problem to be
solved.(sec 3.5) The CS document doesn't mention the issue. It  may go
under the currently empty Authentication and authorization, since some
of our authentication of messages is based using TLS between services.

On 5/10/11 10:05 AM, John MacAuley wrote:
> Mary,
> 
> Good document and I look forward to discussing it tomorrow.  I do have a couple of comments.
> 
> 1. Message Security - I think if you could capture a deployment diagram for the case described it would go a long way to helping people visualize the issue you are trying to address.  I have never signed a SOAP message before so am excited to give it a try :-)
> 
You mean the problem of servers behind a firewall? I'll give it a try.
If things are configured properly, you will never see the message
signing. It is all done by libraries. (if you look at the message on the
wire, you will see a very verbose digital signature in the soap header.)
> 2. Protocol Issues
>> The protocol must be able to pass a list of user, aka subject, attributes
>> in requests to use resources. (not sure why they are included in the
>> confirmed messages.) 
> 
> The original CS protocol document specified them in the request, confirmed, and failed messages.  I would assume some of these will go away as we implement and find no real use for them.
> 
We haven't found a need to authorize reply or fault messages. The fact
that the reply is expected and is passed over a TLS connection from a
known IDC is sufficient to trust it.

> I can modify the schema to change the security attributes to be the equivalent SAML versions.  Did you want the saml:AttributeType or saml:AssertionType?
> 
I don't think I am the person to make that decision. It depends on what
level of transitive trust you think the service providers will require.
Using signed attribute assertions gives a service provider some hops
down the chain more assurance that the original user actually has the
claimed attribute. However, if everyone trusts all the intermediaries to
be honest and not hacked then it  may not be necessary. Also, it is
possible for a fraudulent service to steal and resuse the signed
assertions, so it is not a perfect solution. Since saml assertions have
several required elements they add a level of complexity to the protocol
that just saml attributes do not.
> 3. Message Integrity
>> An end-user may have its own x.509 identity certificate and used signed
>> message or it may access the service via a trusted web portal and use
>> some other means of authentication.
> 
> How will an NSA validate the end-user signature (i.e. how does it get their public certificate?).
The public certificate of the signer should be included in a digital
signature. (The style of digital signatures is one more thing for a
security profile to specify) There are ws-security libraries that will
use that certificate, plus the CA certificates that are stored in a
local secure key store to verify the message signature. The relying
party (NSA) must maintain this list of trusted CA public certificates
(having acquired them off-line by a secure method).  One of the things
that a cooperating group of requesters and providers need to agree upon
is what CAs to trust and how to distribute their certificates.
> 
> 4. Attributes
> 
> Definitely think we shoudl support multiple roles.
One then needs to define how conflicting authorization granted by
multiple roles are combined. We have gone for granting maximum access,
but there are other choices.
> 
> 5. Authorization
> 
> What is the function of the "SpecifySTPList" role?
In OSCARS, ordinary users may only specify the source and destination
elements. NetworkEngineers may specify intermediate elements on a
requested path. These intermediate hops are treated as suggestions, and
the final path might not pass through them. This is considered to be an
extra privilege since the user is trying to manage network traffic.

> 
> Thank you,
> John.
> 
>
>>>> From: John MacAuley <john.macauley at surfnet.nl>
>>>> Date: May 9, 2011 7:27:06 PM PDT
>>>> To: Inder Monga <imonga at es.net>
>>>> Cc: NSI WG <nsi-wg at ogf.org>
>>>> Subject: Re: [Nsi-wg] Starting a discussion on AA
>>>>
>>>> Inder,
>>>>
>>>> I think i will need to see some examples and maybe a couple of use
>>>> cases to help me visualize what you have proposed below.
>>>>
>>>> I had hoped for the prototype we could focus on something simple
>>>> for peer NSA authentication that can be supported by the existing
>>>> technologies with little effort from designers.  For peer NSA
>>>> communications I would propose the following (from my
>>>> presentation in HK).
>>>>
>>>> 1. HTTPS (HTTP over TLS) will be the primary message transport
>>>> mechanism providing encryption, data integrity, and
>>>> certificate-based authentication.
>>>>
>>>> 2. Peer NSA endpoint authentication MUST use bilateral connection
>>>> mode TLS handshaking so any connection can be mutually
>>>> authenticated.  This will require public certificates for trusted
>>>> NSA to be made available on peer NSA servers.  How access to
>>>> these certificates is provided can be consider out of scope of
>>>> this specification.
>>>>
>>>> 3. HTTP Basic authentication or WS-Security basic profile
>>>> (UsernameToken Profile) to validate the WSDL message is from the
>>>> specified peer NSA.
>>>>
>>>> We can then use the parameters in the NSI protocol message for
>>>> additional security such as end user credentials, access control,
>>>> and policies.
>>>>
>>>> John.
>>
>>
>>
>> On 5/5/11 1:07 AM, Inder Monga wrote:
>>> All,
>>>
>>> I am trying to capture the discussion around AA across the day
>>> today
>>> with the actions.
>>>
>>> 1. Pairwise trust between NSAs. This means that ESnet and Internet2
>>> if
>>> they trust each other will agree to exchange NSI messages between
>>>  their
>>> NSAs through a secure connection.
>>>
>>> 2. As part of the pairwise agreement, they may choose to do their
>>> AA
>>> using a specified security profile by OGF NSI group or a common set
>>> of
>>> attributes for a custom security profile they both bilaterally
>>> agree to.
>>>
>>> 3. The NSI message will carry information on the type of security
>>> profile chosen, and then an opaque block of attributes/SAML
>>> assertions/whatever that are specified by the security profile.
>>>
>>> 4. The NSA receiving the message should be able to look at the
>>> security
>>> profile "type" and determine if it can process the AA attributes
>>> block
>>> presented. If it can, it should parse the opaque block and expect
>>> it in
>>> the format as specified by the security profile. If it cannot, it
>>> SHOULD
>>> reject the message, but that really depends on local policy.
>>>
>>> 5. Intermediate NSAs are responsible for translating the security
>>> attributes from the ingress service request to the egress segmented
>>> service requests based on the information available and AA
>>> peer-wise
>>> agreement.
>>>
>>> ***NEW*** 6. A default security profiie SHOULD be supported by all
>>> NSA's
>>> to enhance the chances of interoperability. **WE NEED TO SEE IF
>>> THIS IS
>>> POSSIBLE*****  (this idea was not discussed with the group)
>>>
>>> 7. Security considerations section should be written to clarify the
>>> risks as highlighted in the discussion today and the basis for
>>> adopting
>>> this ie. risk of attribute substitution, but trust is the basis of
>>> accepting pariwise credentials.
>>>
>>> Action: Mary to suggest  a security profile and corresponding
>>> attributes.
>>>
>>> This security profile should be its own document or in the appendix
>>> of
>>> the NSI CS document.
>>>
>>> I hope this captures the discussion from today - please speak up if
>>> I
>>> have not captured the essential spirit of the discussion.
>>>
>>> Thanks,
>>> Inder
>>>
>>>
>>>
>>> --
>>> Inder Monga
>>> 510-486-6531
>>> http://www.es.net
>>> Follow us on Twitter: ESnetUpdates/Twitter <http://bit.ly/bisCAd>
>>> Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3>
>>> Facebook: ESnetUpdates/Facebook <http://bit.ly/d2Olql>
>>>
>>
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: NISAA.rtf
Type: text/rtf
Size: 46507 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110510/7a48cdb4/attachment-0001.rtf 