[Nsi-wg] Starting a discussion on AA

[Inder Monga]

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 <http://bit.ly/bisCAd>
Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3>
Facebook: ESnetUpdates/Facebook <http://bit.ly/d2Olql>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110505/abd48584/attachment.html