Authorization in NSI
Peoples, Before Christmas I pulled together an NSI security omnibus capturing content from Han's AAI document and discussions we had been having on the mechanisms needed to convey security information in the NSI protocol. In addition, I tried to capture the routing policy requirements we have been discussing so I could have a clear view of what issues we are trying to solve. This lead to me writing a proposal for two solutions for the enforcement of end-to-end routing policy that require no changes to the existing CS protocol. As we start preparing for the Washington meeting I have decided to break the document up into three (or four) slide packages for discussion/presentation. I have attached the first of these slide packages. This one deals with the fundamental principles of security in NSI, and the topic of end user Authorization. Included in the slide package is the definition of an "originatingId" as agreed to in Uppsala last September. It captures the identifier of the originating uRA and the identity of the requesting user/application. In addition, it shows how end user authorization information can be generically included in the NSI header for use by end uPA. Thank you, John
Hi On Wed, 4 Feb 2015, John MacAuley wrote:
Before Christmas I pulled together an NSI security omnibus capturing content from Han's AAI document and discussions we had been having on the mechanisms needed to convey security information in the NSI protocol.
Slide 8:
A suggestion was made that we need to introduce a way for downstream NSA to systematically block misbehaving NSA from sending messages into the control plane.
This would change our principle of a control plane of trust, and if we make this step, where do we stop?
How about we stop when we have a good security design? This should include straighforward revocation. The idea that everyone can make requests to everyone, migth not be a good idea. Especially since we don't have a good security model for transit networks.
Do we believe this is a discrete item that needs to be addressed in the protocol?
Slide 10-12: (add URA to security attributes) While I think this might be good idea to add to the security attributes, it is inadequate to use for a revocation mechanism. It introduces a layer between TLS/OAuth identity that must be mapped carefully between the X.509 and the nsa id. If this mapping it not 100% correct, it means that revocation will not work properly. Revocation for an NSA should not rely on the correctness of other NSAs to work. This is bad security design. Request forwarding is extremely tricky to get right from a security point-of-view. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
I am not sure of the procedure for something like this, but if you want to propose the removal of the architectural principle of transitive trust in the control plane, I think you may need a formal contribution. Guy, Tomohiro, Chin? What is the process for requesting a change to one of the NSI fundamental principles? John On 2015-03-09, at 6:11 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi
On Wed, 4 Feb 2015, John MacAuley wrote:
Before Christmas I pulled together an NSI security omnibus capturing content from Han's AAI document and discussions we had been having on the mechanisms needed to convey security information in the NSI protocol.
Slide 8:
A suggestion was made that we need to introduce a way for downstream NSA to systematically block misbehaving NSA from sending messages into the control plane.
This would change our principle of a control plane of trust, and if we make this step, where do we stop?
How about we stop when we have a good security design? This should include straighforward revocation.
The idea that everyone can make requests to everyone, migth not be a good idea. Especially since we don't have a good security model for transit networks.
Do we believe this is a discrete item that needs to be addressed in the protocol?
Slide 10-12: (add URA to security attributes)
While I think this might be good idea to add to the security attributes, it is inadequate to use for a revocation mechanism. It introduces a layer between TLS/OAuth identity that must be mapped carefully between the X.509 and the nsa id. If this mapping it not 100% correct, it means that revocation will not work properly.
Revocation for an NSA should not rely on the correctness of other NSAs to work. This is bad security design.
Request forwarding is extremely tricky to get right from a security point-of-view.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (2)
-
Henrik Thostrup Jensen -
John MacAuley