[Nsi-wg] Starting a discussion on AA

[John MacAuley]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110509/e5debe74/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1791 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110509/e5debe74/attachment.bin