[Nsi-wg] Starting a discussion on AA

Tue May 10 02:46:36 CDT 2011

Dear Inder, 

I am glad you brought this up. We are walking in the realm of what I call "the circle of pain". It is a circle because of the relations between the different (administrative) domains involved. It all boils down to trust. Do I trust SURFnet to "control"/"make reservations" my (ESnet's) network? Since we are dealing with max 25 networks we still could arrange the legal framework around a federation of trust of "NSI" networks. GLIF might be a starting point for such federation. We all commit to that and need to arrange the paperwork around it. NSI deals with the technical implications of that.

We should not forget that it all starts with a researcher that wants to carry out an experiment between UCLA and the UvA (NL) involving huge data streams... Reserving a network is just one part of the equation. He needs to reserve storage and perhaps computing power as well... back to the GRID world... So far, just increasing the problem...

Since in NSI we mostly dealing with machine-2-machine communication, except from the initiation point (request) from an user we should keep it fairly simple as you describe below. The part were it touches on SAML and INCOMMON/EDUGAIN is were the user is involved. At that point the trust is delegated from user level to machine level. The researcher is indeed authorized to make a reservation from all networks between point A and B.

Another point we should consider is that at the time of reservation the user is still authorized to have access at the time of execution of that reservation. If his contract stops as May 30th, but the reservation is for June 10, than it should not be granted... This is not an NSI issue and should be solved by higher layers.

Presumably this did not add to your answer, but my 2c anyway.

Harold

Harold Teunissen - Department Head Middleware Services & Security Officer at SURFnet
LinkedIn | Skype | Twitter | +31 6 1164 0105

On May 10, 2011, at 4:27 AM, John MacAuley wrote:

> 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 2011-05-05, at 2:39 PM, Inder Monga wrote:
> 
>> 
>> Hi All,
>> 
>> 
>> Yesterday we had a few discussions internally that led to the following thoughts on how AA should be tackled for NSI 1.0. This is a very short/briefly written summary of the general direction - these should be elaborated in the CS specification with more explanatory text:
>> 
>> 1. Pairwise trust between NSAs. This means that if NSA A and NSA B trust each other will agree to exchange NSI messages between their NSAs through a secure connection. Authentication mechanisms are needed to establish the secure connection and exchange messages
>> 
>> 2. As part of the pairwise agreement, they may choose to do their AA using a security profile agreed on 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 as part of 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 may have multiple pairwise agreements and are responsible for segmenting the ingress service request. In order to segment the request, they will need to make an appropriate decision, based on local policies and the ingress AA attributes, on what AA information to present to the pairwise NSAs for the various segmented service requests.
>> 
>>   6. A set of default security profiies SHOULD be supported by all NSA's to enhance the chances of interoperability. **We need to see if we can get an agreement on this quickly *****  (FOR EXAMPLE ONLY: A security profile called USERPASS could be chosen which specify the username and password attributes, and how they should be represented, OR a security profile called INCOMMON could be chosen with the set of attributes that have been agreed upon by entities supporting INCOMMON federation for path setup.
>> 
>> 7. The above method is not risk free. Security considerations section should highlight the risks. 
>> 
>> We can discuss this more on the Wednesday morning call - since I have only captured bullet points in this email, some nuances that are important may not get through. I look forward to your comments to this broad direction, so we can decide to put in the effort to specify these security profiles or have some security experts do so.
>> 
>> Inder
>> 
>>   
>> 
>> -- 
>> Inder Monga
>> 510-486-6531
>> http://www.es.net
>> Follow us on Twitter: ESnetUpdates/Twitter 
>> Visit our blog: ESnetUpdates Blog
>> Facebook: ESnetUpdates/Facebook 
>> 
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110510/596f02ba/attachment-0002.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NSI and Circle of Pain.pdf
Type: application/pdf
Size: 229916 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110510/596f02ba/attachment-0001.pdf 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110510/596f02ba/attachment-0003.html 