- Nsi-wg - lists.ogf.org

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

nsaAddress semantics
by John MacAuley 10 May '11

10 May '11

Peoples, There was a proposal to use the nsaAddress field to hold the protocol specific endpoint. This would allow the removal of the "replyTo" field in the WSDL. I originally had concerns about the lack of endpoint decoupling of the confirm and failed messages from the request endpoint, however, I am over the concern now and do not see a reasonable reason for an NSA to need this decoupling. So if there are no concerns from the group, I would like to simplify things by removing the replyTo element and instead utilize the nsaAddress element. Comments? John.

1 0

minutes from today's NSI call
by Guy Roberts 08 May '11

08 May '11

The minutes from today's NSI call are available here: http://forge.gridforum.org/sf/go/doc16256?nav=1 _____________________________________________________________________ ** 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 _____________________________________________________________________

5 11

Forwarding to NSI group - from NML group
by Inder Monga 07 May '11

07 May '11

Please review the draft documents and send comments to Freek or NML mailing list. Inder > ------------------------------------------------------------------------ > > *From:* Freek Dijkstra <Freek.Dijkstra(a)sara.nl> > *Date:* May 7, 2011 1:44 PM > *To:* Network Markup Language Working Group <nml-wg(a)ogf.org> > *Subject:* [Nml-wg] urn:ogf:network specification > > > All, > > I finally written or updated three documents: > > 1. Delegation of urn:ogf to the OGF > 2. Procedure for registration of namespaces within urn:ogf > 3. Specification of urn:ogf:network (also attached) > > All documents can be found in the repository at > http://forge.ogf.org/svn/repos/urn-ogf-docs > > Only document #3 is in scope of the NML working group. > I welcome feedback for all documents though. > > Delegation of urn:ogf to the OGF > ================================ > See http://tools.ietf.org/html/draft-dijkstra-urn-ogf > > Please sent comment to me off-list or to the urn-nid(a)ietf.org mailing list. > > Procedure for registration of namespaces within urn:ogf > ======================================================= > See http://forge.ogf.org/sf/go/artf6478 > > Please leave comments at this artifact or sent them to me off-list. > > Specification of urn:ogf:network > ================================ > See http://forge.gridforum.org/sf/go/doc16260 > > Please sent comments to the NML-WG mailing list or sent them to me off-list. > > I certainly appreciate feedback on the following two issues. > > Compatibility with GLIF and perfSONAR usage > ------------------------------------------- > > The current syntax is compatible with both current usage, although it is > now specified that recipients of a URN SHOULD NOT interpret the local > part. This is a change from the existing use. > > Also, the document specifies that the following two URNs are NOT lexical > equivalent. I have no opinion on this. Should this be equivalent or not? > - urn:ogf:network:example.net:path:2011-0418 > - urn:ogf:network:domain=example.net:path:2011-0418 > > International Characters > ------------------------ > > No international characters are allowed. I actually worked out a solid > schema (using RFC 5982 and NFKD normalisation that would allow quite a > few code points, but still have a very simple URN comparison -- no > decoding required.), but decided not to use it. > > I was finally convinced NOT to allow international characters by the > following comments on the urn(a)ietf.org list: > > If you allow people to assign URNs as they prefer, they always > tend to "invent" some semantic rules. > > At the end you have your database full of Identifiers like: > [institution]-[division]-[collection-name]-[date]-[item-number] > > This goes fine many years. > Till the day the collections are renamed or two divisions fusion > under another name or renaming of the institution or ... > > Experiences like those are the reason why many colleagues with > Long Term Archiving background propagate Identifiers without > semantics --meaningless strings just for machines. > > IMHO that is the problem and not if those meaningful-names written > in Kanji, Chinese, Arabic or Krill. > > Seriously I would allow ONLY numbers and 3-4 separator chars if I > could define a new generation ID system. That is NOT "restrictive" > but functional and problem free. > > (source: http://www.ietf.org/mail-archive/web/urn/current/msg01564.html) > > > Regards, > Freek > _______________________________________________ > nml-wg mailing list > nml-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/nml-wg

1 0

Comments on NSI CS WSDLs and XSD
by Chin Guok 04 May '11

04 May '11

Feedback on the NSI WSDL's: NSI Connection Interface WSDL ------------------------------------------- - The names of messages should be discussed. It is suggested that opposites be chosen to make the function of the messages more obvious for example Provision and Unprovision, Reserve and Unreserve, etc. In any case, before we finalize the 1.0 specification, some more thought needs to be put into the naming. - The replyTo in the NSI CS request message contains the callback SOAP address. Does it places constraint if the RA is behind a NAT'ed address? We may need implementation guidance on this scenario [there are multiple options like SOAP proxy, Broker etc.] - transaction ID: the soft guidance on the transaction ID does not help since if there is a possibility that the ID is not global, the software cannot take advantage of it if it is globally unique. The group should decide on one or the other i.e. either mandate it Global or do not provide any guidance (other than the fact that it should be locally unique). - Notification message for out of bound messaging from the PA to RA should be considered as a way for the network to notify the RA of exceptions. A Notify message with restrictions on CS Service oriented notifications only should be put in place as a general notification service is not yet defined, and may not be standardized for a while. NSI Connection Types XSD --------------------------------------- - Need to understand better the rationale between choosing the current format of NsiExceptionType as a concatenation string with variables. Wouldn't key/value pairs be more useful and easily allow interpretation at both ends through standardized key-value pairs? - nsaAddress should be defined. Can it be used as a callback URI? It will be nice to have it as the same format as the replyTo address above. - Bandwidth should not be mandatory. This is a connection service, bandwidth should be optional. - For the NSI Message Types, the ReserveType (for example), stands for both ReserveRequest and ReserveResponse. Should there be a ResponseType that is different? - Can names of the states as defined in ConnectionStateType be "normalized" to better reflect the messages, e.g. there is canceling, but terminated is used instead of canceled Thanks ESnet OSCARS developers

2 2

NSI call today?
by Radek Krzywania 04 May '11

04 May '11

Hi, Do we have a call today? Didn't see any notification from Guy recently. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania(a)man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

2 1