May 2011 - Nsi-wg - lists.ogf.org

Draft NSI Connection Service Protocol document
by Guy Roberts 06 Jul '11

06 Jul '11

I have updated the NSI connection service protocol document to reflect the current discussions. This is intended to incorporate both the NSI connection service protocol details and sufficient contextual discussion to allow this protocol to be implemented. There will no longer be an NSI connection service architecture document. You can find a copy here: http://forge.gridforum.org/sf/go/doc16045?nav=1 All feedback is welcome. Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

2 4

Tomorrow's NSI call
by Guy Roberts 31 May '11

31 May '11

Hi all, The following is dial-in information for tomorrow's NSI call: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 23:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0

tomorrow's NSI call
by Guy Roberts 18 May '11

18 May '11

Hi all, The following is dial-in information for tomorrow's NSI call: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 23:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Agenda: Review the CS protocol standard: http://forge.gridforum.org/sf/go/doc16045?nav=1 Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 1

state machine with "failed" states
by Tomohiro Kudoh 11 May '11

11 May '11

How about this?

2 1

behavior state machines
by Tomohiro Kudoh 11 May '11

11 May '11

Hi all Here are sample behavior state machines. (just for reference, not very complete) Tomohiro

1 0

state machine
by Tomohiro Kudoh 11 May '11

11 May '11

Hi all, Here is the state machine which I think is the latest. Tomohiro

1 0

today's NSI conf call (TIME CHANGE!!)
by Tomohiro Kudoh 11 May '11

11 May '11

Hi all, Due to some scheduling conflict, today's NSI conf call will be started one hour later than usual. The following is dial-in information for the NSI call: 8:00 PDT 11:00 EDT, 16:00 GMT, 17:00 CET, 24:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" --- Tomohiro Kudoh t.kudoh(a)aist.go.jp Grid Infraware Research Group, Information Technology Research Institute National Institute of Advanced Industrial Science and Technology (AIST) Tsukuba-Central 2, 1-1-1 Umezono Tsukuba Ibaraki 305-8568 Japan Phone: +81-29-861-5761 Fax: +81-29-862-6601

1 0

AA document by Mary Thompson
by Inder Monga 11 May '11

11 May '11

Hi Folks, Please review the document and email by Mary. Best Regards, Inder > > -------- Original Message -------- > Return-Path:<mrthompson(a)lbl.gov> > > Date: Tue, 10 May 2011 14:58:29 -0700 > From: Mary Thompson<mrthompson(a)lbl.gov> > Reply-To: mrthompson(a)lbl.gov > > CC: Mary R Thompson<MRThompson(a)lbl.gov> > Subject: Fwd: Re: Capturing AA discussion > > X-Enigmail-Version: 1.1.1 > Content-Type: multipart/mixed; > boundary="------------070500080408020603000708" > > 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.

1 0

Fwd: Re: Capturing AA discussion
by Mary Thompson 10 May '11

10 May '11

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(a)lbl.gov> Date: Tue, 10 May 2011 12:10:11 -0700 From: Mary Thompson <mrthompson(a)lbl.gov> To: John MacAuley <john.macauley(a)surfnet.nl> CC: Inder Monga <imonga(a)es.net>, Jerry Sobieski <jerry(a)sobieski.net>, Chin Guok <chin(a)es.net>, Evangelos Chaniotakis <haniotak(a)es.net>, "Eric lomax(a)es.net" <lomax(a)es.net>, kleist(a)nordu.net, Andy Lake <andy(a)es.net>, Mary R Thompson <MRThompson(a)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? > 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. > 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 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(a)surfnet.nl> >>>> Date: May 9, 2011 7:27:06 PM PDT >>>> To: Inder Monga <imonga(a)es.net> >>>> Cc: NSI WG <nsi-wg(a)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> >>> >> >>

1 0

Starting a discussion on AA
by Inder Monga 10 May '11

10 May '11

Hi All, Yesterday we had a few discussions internally that led to the following thoughts on how AA should be tackled for NSI 1.0. This is a very short/briefly written summary of the general direction - these should be elaborated in the CS specification with more explanatory text: 1. Pairwise trust between NSAs. This means that if NSA A and NSA B trust each other will agree to exchange NSI messages between their NSAs through a secure connection. Authentication mechanisms are needed to establish the secure connection and exchange messages 2. As part of the pairwise agreement, they may choose to do their AA using a security profile agreed on 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 as part of 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 may have multiple pairwise agreements and are responsible for segmenting the ingress service request. In order to segment the request, they will need to make an appropriate decision, based on local policies and the ingress AA attributes, on what AA information to present to the pairwise NSAs for the various segmented service requests. 6. A set of default security profiies SHOULD be supported by all NSA's to enhance the chances of interoperability. **We need to see if we can get an agreement on this quickly ***** (FOR EXAMPLE ONLY: A security profile called USERPASS could be chosen which specify the username and password attributes, and how they should be represented, OR a security profile called INCOMMON could be chosen with the set of attributes that have been agreed upon by entities supporting INCOMMON federation for path setup. 7. The above method is not risk free. Security considerations section should highlight the risks. We can discuss this more on the Wednesday morning call - since I have only captured bullet points in this email, some nuances that are important may not get through. I look forward to your comments to this broad direction, so we can decide to put in the effort to specify these security profiles or have some security experts do so. 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>

3 2