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