I have attached some suggestions for specifying message authentication and authorization of resources in the NIS documents and SC schema. This document is the result of a meeting held last Tues and Wednesday with Inder Monga, Jerry Sobieski, Josva Kleist, Chin Guok, Evangelos Chaniotakis, Eric Lomax, Andy Lake and Mary Thompson. I have also included the highlights of the discussion that has taken place in email. As I have a background in distributed and grid AA issues, Inder asked me to suggest a possible attribute profile that could be adopted in the near future. I went a bit further and addressed the issue of message security as well. The attached document is for discussion and suggests alternatives and possibilities. I think the decision of what to do needs to be made by the group as a whole making the best guess they can as to what level of security the service providers will require and the users will be able to comply with. Mary Thompson Note: I am not on the nsi-wg mailing list, so cc me on anything you want me to read. -------- Original Message -------- Return-Path: <mrthompson@lbl.gov> Date: Tue, 10 May 2011 12:10:11 -0700 From: Mary Thompson <mrthompson@lbl.gov> To: John MacAuley <john.macauley@surfnet.nl> CC: Inder Monga <imonga@es.net>, Jerry Sobieski <jerry@sobieski.net>, Chin Guok <chin@es.net>, Evangelos Chaniotakis <haniotak@es.net>, "Eric lomax@es.net" <lomax@es.net>, kleist@nordu.net, Andy Lake <andy@es.net>, Mary R Thompson <MRThompson@lbl.gov> Subject: Re: Capturing AA discussion In response to Inder's comment: Any "security profile" is going to have to specify the how message security is handled as well as how it supports authorization. I agree that they are two distinct topics, but both need to be covered. I notice that the framework document states that it is a problem to be solved.(sec 3.5) The CS document doesn't mention the issue. It may go under the currently empty Authentication and authorization, since some of our authentication of messages is based using TLS between services. On 5/10/11 10:05 AM, John MacAuley wrote:
Mary,
Good document and I look forward to discussing it tomorrow. I do have a couple of comments.
1. Message Security - I think if you could capture a deployment diagram for the case described it would go a long way to helping people visualize the issue you are trying to address. I have never signed a SOAP message before so am excited to give it a try :-)
You mean the problem of servers behind a firewall? I'll give it a try. If things are configured properly, you will never see the message signing. It is all done by libraries. (if you look at the message on the wire, you will see a very verbose digital signature in the soap header.)
2. Protocol Issues
The protocol must be able to pass a list of user, aka subject, attributes in requests to use resources. (not sure why they are included in the confirmed messages.)
The original CS protocol document specified them in the request, confirmed, and failed messages. I would assume some of these will go away as we implement and find no real use for them.
We haven't found a need to authorize reply or fault messages. The fact that the reply is expected and is passed over a TLS connection from a known IDC is sufficient to trust it.
I can modify the schema to change the security attributes to be the equivalent SAML versions. Did you want the saml:AttributeType or saml:AssertionType?
3. Message Integrity
An end-user may have its own x.509 identity certificate and used signed message or it may access the service via a trusted web portal and use some other means of authentication.
How will an NSA validate the end-user signature (i.e. how does it get their public certificate?). The public certificate of the signer should be included in a digital signature. (The style of digital signatures is one more thing for a security profile to specify) There are ws-security libraries that will use that certificate, plus the CA certificates that are stored in a local secure key store to verify the message signature. The relying
I don't think I am the person to make that decision. It depends on what level of transitive trust you think the service providers will require. Using signed attribute assertions gives a service provider some hops down the chain more assurance that the original user actually has the claimed attribute. However, if everyone trusts all the intermediaries to be honest and not hacked then it may not be necessary. Also, it is possible for a fraudulent service to steal and resuse the signed assertions, so it is not a perfect solution. Since saml assertions have several required elements they add a level of complexity to the protocol that just saml attributes do not. party (NSA) must maintain this list of trusted CA public certificates (having acquired them off-line by a secure method). One of the things that a cooperating group of requesters and providers need to agree upon is what CAs to trust and how to distribute their certificates.
4. Attributes
Definitely think we shoudl support multiple roles.
One then needs to define how conflicting authorization granted by multiple roles are combined. We have gone for granting maximum access, but there are other choices.
5. Authorization
What is the function of the "SpecifySTPList" role?
In OSCARS, ordinary users may only specify the source and destination elements. NetworkEngineers may specify intermediate elements on a requested path. These intermediate hops are treated as suggestions, and the final path might not pass through them. This is considered to be an extra privilege since the user is trying to manage network traffic.
Thank you, John.
From: John MacAuley <john.macauley@surfnet.nl> Date: May 9, 2011 7:27:06 PM PDT To: Inder Monga <imonga@es.net> Cc: NSI WG <nsi-wg@ogf.org> Subject: Re: [Nsi-wg] Starting a discussion on AA
Inder,
I think i will need to see some examples and maybe a couple of use cases to help me visualize what you have proposed below.
I had hoped for the prototype we could focus on something simple for peer NSA authentication that can be supported by the existing technologies with little effort from designers. For peer NSA communications I would propose the following (from my presentation in HK).
1. HTTPS (HTTP over TLS) will be the primary message transport mechanism providing encryption, data integrity, and certificate-based authentication.
2. Peer NSA endpoint authentication MUST use bilateral connection mode TLS handshaking so any connection can be mutually authenticated. This will require public certificates for trusted NSA to be made available on peer NSA servers. How access to these certificates is provided can be consider out of scope of this specification.
3. HTTP Basic authentication or WS-Security basic profile (UsernameToken Profile) to validate the WSDL message is from the specified peer NSA.
We can then use the parameters in the NSI protocol message for additional security such as end user credentials, access control, and policies.
John.
On 5/5/11 1:07 AM, Inder Monga wrote:
All,
I am trying to capture the discussion around AA across the day today with the actions.
1. Pairwise trust between NSAs. This means that ESnet and Internet2 if they trust each other will agree to exchange NSI messages between their NSAs through a secure connection.
2. As part of the pairwise agreement, they may choose to do their AA using a specified security profile by OGF NSI group or a common set of attributes for a custom security profile they both bilaterally agree to.
3. The NSI message will carry information on the type of security profile chosen, and then an opaque block of attributes/SAML assertions/whatever that are specified by the security profile.
4. The NSA receiving the message should be able to look at the security profile "type" and determine if it can process the AA attributes block presented. If it can, it should parse the opaque block and expect it in the format as specified by the security profile. If it cannot, it SHOULD reject the message, but that really depends on local policy.
5. Intermediate NSAs are responsible for translating the security attributes from the ingress service request to the egress segmented service requests based on the information available and AA peer-wise agreement.
***NEW*** 6. A default security profiie SHOULD be supported by all NSA's to enhance the chances of interoperability. **WE NEED TO SEE IF THIS IS POSSIBLE***** (this idea was not discussed with the group)
7. Security considerations section should be written to clarify the risks as highlighted in the discussion today and the basis for adopting this ie. risk of attribute substitution, but trust is the basis of accepting pariwise credentials.
Action: Mary to suggest a security profile and corresponding attributes.
This security profile should be its own document or in the appendix of the NSI CS document.
I hope this captures the discussion from today - please speak up if I have not captured the essential spirit of the discussion.
Thanks, Inder
-- 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>