We delegated the issue of NSA-to-NSA authentication to the transport layer. We will also validate message integrity and that the message is coming form the expected NSA. NSA-to-NSA authorization is a local implementation issue based on the establishment of trust, however, I believe Mary's accepted proposal was to do user based authorization on each message using the user context provided in the security parameters. We really do not have the concept of a long duration session in the NSI protocol. Each message exchange is a discrete event in which an NSA can connect, authenticate, send, and tear down the transport.

On 2011-08-08, at 4:01 PM, Jerry Sobieski wrote:

John - this may be for you...

In reviewing this issue on the RA/PA... I went looking at the UML doc Guy circulated as it is a bit easier to read than the raw WSDL...

The messages all have the requesterNSAID and the providerNSAID fields, directly folowed by the "sessionSecurityID".   This is the only field I see for security attributes.

I thought our conclusion was that there would be two security layers: a NSA session level authentication/authorization credentials, and a request level authorization credential that would authorize the particular action requested relative to the resource or information context of the request. Does this sessionSecirity field do double duty authenticating the remote NSA *and* authorizing the particular service request?

I trust the MTL to authenticate the messaging, as the NSI layer should never see messages from an unauthenticated NSA.   But the NSI layer does need the authorization credentials in order to properly evaluate the primitive... The authorization of an NSI request is not an MTL function.   So I am just a bit unsure how this field is planned to be used within the WSDL.

Thoughts/Comments?
Jerry

_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg