Going through the effort of provisioning a peer NSA and associated public key certificates would indicate to me that I have set up a level of trust with that NSA and am willing to accept any messages sent to me as part of that trust establishment.  However, do we believe that the processing of that message may be influenced based on the NSA from which it arrived, or is this purely based on the original user associated with the message?  Of course, I may put administrative limits on the number of messages received per second/hour/day, but I can't restrict the actual processing of CS messages once received?

I have always taken the position that authorization of the CS message and access to local resources needs to be based on the user credentials supplied in the message.  I believed a user should get a similar experience within the network regardless of the path his/her message takes through the NSA tree.  For example, if Bob issues a message to his local NSA A which then passes the message to NSA B and then on to NSA C where the connection is authorized and reserved, I do not think it should be possible to fail that same message if routing sent the message from A->D->C.  If A has a trusted relationship with B and D, and B and D have a trusted relationship with C, why would we get different behaviours from a CS protocol perspective if B and D are just transit NSA?

Should NSA D be able to enforce a policy that says I will not route messages from NSA A to NSA C?  This implies that trust is not transitive from a CS messaging perspective even though the reservation would ultimately succeed.  I guess we need to step back and ask why would NSA A use NSA D to route a message to NSA C?  Obviously NSA D incorrectly advertised to NSA A the reachability to NSA C.

Hmmm... Okay, I have talked myself into the need for an NSA to enforce local policy rules based on the source and destination NSA.  I may want to stop a public facing NSA from routing through to a private network segment, however, I should never advertise that private segment to the public facing NSA to try and avoid false positives on path computation.

John.

On 2011-08-08, at 11:33 PM, Inder Monga wrote:

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
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
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
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
Visit our blog: ESnetUpdates Blog
Facebook: ESnetUpdates/Facebook