On 2011-08-09, at 11:03 AM, Jerry Sobieski wrote:
Hey John- Let me try to answer some of these scenarios:
On 8/9/11 8:59 AM, John MacAuley wrote:
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?
Neither, if we are pedantic about terms here:-) Authorization of the request is based upon the credentials that are associated with the request (not the NSA or the message per se). It matters not from which NSA the request came, nor does it matter if the credentials presented are those of the original requester or not. All an NSA knows is what it finds in the inbound request message. Its impossible (as currently defined) to know the provenance of that request or the provided credentials from just the request itself. (This does open up a discussion about possibly extending the query to work *up* the tree to find the provenance of a request rather than just down the tree as currently defined - under authorization of course. ...This is v2.0 though.)
Hmmm... through my twisted path to enlightenment I think there are cases where we might want to authorize messages from an NSA. I would be willing to ignore the issue for now though.
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? There are a lot of ways and reasons to block NSA-to-NSA communication. We need to make sure that the protocol - particularly the MTL - handles all such situations in a finite state machine. I.e. if communications is blocked, the protocol should be able to handle it appropriately. I think the MTL returns a "undeliverable message" exception to the sending NSA if the session cannot be established and the message queued for the remote NSI processing. Right? As long as the protocol can deal with rejection or failure to communicate in a predictable fashion, we are ok. We just can't abide surprises.
Yes, we can definitely send back appropriate error messages. The current transport has the capabilities.
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?
First, messages aren't authorized, *requests* are authorized. messages are just containers.
Poh-tey-toe/poh-tah-toh :-)
More to th epoint: NSA Bob's reservation request is authorized at A according to the associated authorization credentials found in the message (presumably "userid=Bob") and NSA A's local authorization policy. Assuming it passes A's authorization, then NSA A then issues a subsequent reservation request message to B, presumably (but not necessarilly) containing the same userid authorization. NSA B authorizes the specific request from A according to the authorization credntials presented, and B's local authorization policy. (Note- B may have different authorization profiles from A) This sequence could go on forever. NSA A could pass along userid=Bob credentials, or NSA A could alternatively decide to use a different set of credentials it deems appropriate for this request. So, B does not know (or care IMO) who is the ultimate RA...all B knows is that a request came from A containing a particular set authorization credentials. B will act on that information alone.
100% agree with this aspect.
If Bob's userid is recognized at NSA C, then Bob can just send the request directly to C. IF for some reason Bob cannot contact C (e.g. no session authorization, or Bob does not know of C at all) then Bob is at the mercy of NSA A and/or NSA B. We do not punch thru an NSA's security simply because it does not provide a local segment or we expect some down stream network to actually provide the resources. In our model, messages do not transparently transit any NSA - all messages are processed at each NSA. The service requests carried in the messages cause a tree to be constructed. In the case above, the service tree includes Bob (ultimate RA), NSA A, NSA B, and NSA C (ultimate PA). If NSA A elects to build a different tree by either transiting network D or bypassing B and D altogether and going directly to C, that is NSA A's internal choice and Bob has little (if any) formal control over it.
There is a clear separation between NSA resources Bob is authorized to use and NSAs that Bob is permitted to authenticate against directly. We can't assume both are the same.
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.
Ah you make *WAY* too many assumptions.
I assume nothing grasshopper.
First, advertising reachability - NSI has no current idea of advertising any routing or topology. An NSA *magically* knows of a topology map - we make no assertions of how it learned that information or its validity.
Yes. This is the 50 foot festering hole in our current activities. I love solutions that require magic and hand-waving.
Second, trust is not a protocol issue. Authorization policies embody the trust: Each NSA has the power to allow or deny *any* transaction across its network based soley on its own local policies. "Trust" is established when two networks mutually agree to implement a common set of policies that allow certain transactions to occur between them. They trust each other. By definition, if local policy does not allow certain interactions, then those interactions are not trusted. And vice versa: if two networks trust one another, it is measured by their mutual adoption of appropriate common/shared authorization strategies (Policies).
The protocol must have the ability to relay information that permits enforcement of policies, whether authentication, authorization, or other AAA type policies. Trust is one of these types of AAA issues. We have defined security attributes within the protocol to relay user information permitting AAA enforcement, but have hand-waved the implementation side of the issue. In the end there is a dependency.
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.
:-) There is an old monty python skit where an old lady claims victory in an argument "See there! I'm running rings around you logically!"
Best regards Jerry
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