[Nsi-wg] Starting a discussion on AA
Inder Monga
imonga at es.net
Thu May 5 13:39:46 CDT 2011
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
More information about the nsi-wg
mailing list