Jerry and John,
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. Hmm...This sounds rather murky. What do you mean based on establishment of trust? If you mean an NSA is free to accept or reject another NSA's session on purely local whim (i.e. arbitrary local policy) then we should be specific and clear about it. (BTW- I actually agree with this:-) Trust could be based on a simple thing as "administrative configuration" or more extensive process?
Inder
I presume then that there is a userid in the sessionSecurityID field somewhere? Can we spec this out in detail for the coders what the "user" authorization profile info will look like in the security attribute?
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. Ok, this makes me fidgety, but its not an issue at the moment.
Thanks for elaborating...all is clearer now. Jerry
John.
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 <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
John MacAuley <mailto:john.macauley@surfnet.nl> August 8, 2011 4:38 PM
Jerry,
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.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
Jerry Sobieski <mailto:jerry@nordu.net> August 8, 2011 1:01 PM
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
-- 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>