I propose the following high level approach for V1: We have defined two levels of AA: "Session layer" between NSAs, and "Request layer" at the primitive/connection context. I pose we define a "security attributes" element that consists of: a) Security Type := Identifies the security mechanism this element provides. b) Secutity Credentials := Contains a string of security information to be interpreted by the mechanism specified in the Type field. When initializing the NSA to NSA session, this element will authenticate each NSA to the other, and then each NSA will decide whether the other [remote] NSA is authorized to communicate with the local NSA. For any service request, the request must be authorized. The Service Definition will specify the set of recognized and allowable AA mechanisms for each network. The user request must specify one allowable mechanism in the service request. Initially, the NSI CS spec will require NSAs to recognize and support two levels of security: a) "simple security" consisting of a string passed to the authorizing agent for lookup in a flat text file, b) "better security" a more sophisticated AA scheme such as X509 or the like (details TBD by someone who understands these issues in greater detail.) I will code this into the XSD for the Service Defs. Any comments or additional necessary detail, please let me know. Jerry
I would prefer to have the lower level security for protocol development purposes only, otherwise it gets selected by default in deployment. Is that possible while meeting the objectives of simple security? Inder
------------------------------------------------------------------------
Jerry Sobieski <mailto:jerry@nordu.net> March 30, 2011 10:01 AM
I propose the following high level approach for V1:
We have defined two levels of AA: "Session layer" between NSAs, and "Request layer" at the primitive/connection context.
I pose we define a "security attributes" element that consists of: a) Security Type := Identifies the security mechanism this element provides. b) Secutity Credentials := Contains a string of security information to be interpreted by the mechanism specified in the Type field.
When initializing the NSA to NSA session, this element will authenticate each NSA to the other, and then each NSA will decide whether the other [remote] NSA is authorized to communicate with the local NSA.
For any service request, the request must be authorized. The Service Definition will specify the set of recognized and allowable AA mechanisms for each network. The user request must specify one allowable mechanism in the service request.
Initially, the NSI CS spec will require NSAs to recognize and support two levels of security: a) "simple security" consisting of a string passed to the authorizing agent for lookup in a flat text file, b) "better security" a more sophisticated AA scheme such as X509 or the like (details TBD by someone who understands these issues in greater detail.)
I will code this into the XSD for the Service Defs. Any comments or additional necessary detail, please let me know.
Jerry _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
I think it is up to the network and not a standards issue which authentication mech a service uses. IMO The standards issue is a) what authentication mechs this protocol is required to recognize and b) how that authenticated user is used in an authorization context. We have not formally defined NSI authorization context. We need to do this so that we clearly define what objects and processes are subject to authorization. Eg what authorization is required to access RA connection info vs PA connection info? We've argued a bit about this, but have no formal NSI AA context/environment defined. I suggest we provide a very basic AA context for v1. This is not weak security, just very simple roles and policy. I will draft a 1ish page AA Policy context section for review and discussion. This will bound what v1 requires. J Sent from my iPhone On Mar 31, 2011, at 3:38 AM, Inder Monga <imonga@es.net> wrote:
I would prefer to have the lower level security for protocol development purposes only, otherwise it gets selected by default in deployment. Is that possible while meeting the objectives of simple security?
Inder
<postbox-contact.jpg> Jerry Sobieski March 30, 2011 10:01 AM
I propose the following high level approach for V1:
We have defined two levels of AA: "Session layer" between NSAs, and "Request layer" at the primitive/connection context.
I pose we define a "security attributes" element that consists of: a) Security Type := Identifies the security mechanism this element provides. b) Secutity Credentials := Contains a string of security information to be interpreted by the mechanism specified in the Type field.
When initializing the NSA to NSA session, this element will authenticate each NSA to the other, and then each NSA will decide whether the other [remote] NSA is authorized to communicate with the local NSA.
For any service request, the request must be authorized. The Service Definition will specify the set of recognized and allowable AA mechanisms for each network. The user request must specify one allowable mechanism in the service request.
Initially, the NSI CS spec will require NSAs to recognize and support two levels of security: a) "simple security" consisting of a string passed to the authorizing agent for lookup in a flat text file, b) "better security" a more sophisticated AA scheme such as X509 or the like (details TBD by someone who understands these issues in greater detail.)
I will code this into the XSD for the Service Defs. Any comments or additional necessary detail, please let me know.
Jerry _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Of course we need to clearly distinguish the differences between transport level security provided by a specific implementation instance, and these someone undefined security securityAttr we have stuffed into the CS protocol specification (and in the XSD). From an implementation instance we will use TLS mutual authentication using provisioned digital certificates to set up an encrypted trust relationship between a pair of servers, and basic user ID and passwords to identify the NSA issuing requests. I am still interested in examples of the securityAttr associated with the common parameters and NSATypes. I would like to make sure we use the existing tns:AttributeSequenceType definition for type/value pairs instead of a specific definition every time we get another field we think is special. For example, SecurityType == attributeName and Security Credentials == attributeValue. Simple reuse and no confusion. John On 2011-03-31, at 6:53 AM, Jerry Sobieski wrote:
I think it is up to the network and not a standards issue which authentication mech a service uses. IMO The standards issue is a) what authentication mechs this protocol is required to recognize and b) how that authenticated user is used in an authorization context.
We have not formally defined NSI authorization context. We need to do this so that we clearly define what objects and processes are subject to authorization. Eg what authorization is required to access RA connection info vs PA connection info? We've argued a bit about this, but have no formal NSI AA context/environment defined.
I suggest we provide a very basic AA context for v1. This is not weak security, just very simple roles and policy. I will draft a 1ish page AA Policy context section for review and discussion. This will bound what v1 requires.
J
Sent from my iPhone
On Mar 31, 2011, at 3:38 AM, Inder Monga <imonga@es.net> wrote:
I would prefer to have the lower level security for protocol development purposes only, otherwise it gets selected by default in deployment. Is that possible while meeting the objectives of simple security?
Inder
<postbox-contact.jpg> Jerry Sobieski March 30, 2011 10:01 AM
I propose the following high level approach for V1:
We have defined two levels of AA: "Session layer" between NSAs, and "Request layer" at the primitive/connection context.
I pose we define a "security attributes" element that consists of: a) Security Type := Identifies the security mechanism this element provides. b) Secutity Credentials := Contains a string of security information to be interpreted by the mechanism specified in the Type field.
When initializing the NSA to NSA session, this element will authenticate each NSA to the other, and then each NSA will decide whether the other [remote] NSA is authorized to communicate with the local NSA.
For any service request, the request must be authorized. The Service Definition will specify the set of recognized and allowable AA mechanisms for each network. The user request must specify one allowable mechanism in the service request.
Initially, the NSI CS spec will require NSAs to recognize and support two levels of security: a) "simple security" consisting of a string passed to the authorizing agent for lookup in a flat text file, b) "better security" a more sophisticated AA scheme such as X509 or the like (details TBD by someone who understands these issues in greater detail.)
I will code this into the XSD for the Service Defs. Any comments or additional necessary detail, please let me know.
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
participants (3)
-
Inder Monga -
Jerry Sobieski -
John MacAuley