[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Re: Proposed Agenda for SSTC Conference Call(Tue 21 Sept 2010)
On 09/21/2010 12:42 PM, Nate Klingenstein wrote: > >> 2. Need a volunteer to take minutes. > Voting Members: John Bradley Individual Scott Cantor Internet2 Nathan Klingenstein Internet2 Bob Morgan Internet2 Thomas Hardjono M.I.T. Anthony Nadalin Microsoft Corporation Frederick Hirsch Nokia Corporation Thinh Nguyenphu Nokia Siemens Networks GmbH & Co. KG Paul Madsen NTT Corporation Hal Lockhart Oracle Corporation Emily Xu Oracle Corporation Anil Saldhana Red Hat David Staggs Veterans Health Administration Members: Federico Rossini Telecom Italia S.p.a. Duane DeCouteau Veterans Health Administration Phil Hunt Oracle Corporation Quorum: 13 of 17 (76%) Achieved: Status Changes: FedericoR gains voting rights. Rob Philpott and George Fletcher lose voting rights. > Nate volunteered. Quorum was achieved. > >> 3. Approval of minutes from last meetings: >> >> Minutes from SSTC Call on 7 Sept 2010: >> >> http://www.oasis-open.org/apps/org/workgroup/security/email/archives/201009/msg00016.html >> > > Anil moved to approve the minutes and Scott seconded. The minutes > were approved. > >> (c) SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0 as >> a CS >> - Status: CS created and publsihed. >> >> (d) SAML V2.0 Holder-of-Key Assertion Profile Version 1.0 >> - Status: CS created and publsihed. > > These have both been created and published. Nate has not updated the > Wiki yet, but will do so. > >> (e) Kerberos related items. [Josh/Thomas] >> - Kerberos Attribute Profile: >> - AI: Josh/Thomas will suggest additions to Attribute Profile. > > The profile is still being retooled alongside the team from CMU who > provided the additional use case discussed in prior minutes. The > revision is probably almost done and an updated version should land in > the SSTC within the next several weeks. > >> (f) SAML V2.0 Identity Assurance Profiles, Version 1.0 >> - Status: 15-day review closed on 10 Sept. >> - Any comments received? > > Bob and Scott were not aware of any further comments received on the > Profiles. > > Paul attested to the fact that no further comments were received, that > CD-02 was reaffirmed and unchanged; Scott seconded it. No objections > or concerns were raised. Nate then moved to create a CS ballot for > CD-02 of the Identity Assurance Profiles. Paul seconded Nate's > motion. Thomas will submit a request to Mary for the ballot. > >> (g) SAML V2.0 Metadata Profile for Algorithm Support Version 1.0: >> - Status: now in 60-day public review. (Closes 13 October) >> - Any updates? > > Scott had observed that the examples were broken in this profile, and > he'll update a new working draft shortly. > >> (h) Service Provider Request Initiation Protocol and Profile >> Version 1.0 >> - Status: now in 60-day public review. (Closes 13 October) >> - Any updates? > > No updates. > >> (i) NSN Attribute Management proposal (Thinh/Phil) - any updates? > > Draft 2 was sent to the list on Monday. > > The terminology has been cleaned up so that notify issuer and notify > target are more explicit. The references have been updated. The core > protocol is largely the same; the major change is that instead of > using a SAML subject, a SAML NameID/EncryptedID is referenced in the > schema instead. > > Front-channel and back-channel have been renamed to asynchronous and > synchronous. The terminology here is meant to match the rest of > SAML's terminology. Scott said this was never deeply discussed, and > the goal was to create profiles that were not specifically tied to > bindings. The goal was to keep bindings separate from profiles, and > Scott came up with arbitrary categories for those bindings. > > Scott suggested the examples be moved to the core protocol section. > > In retrospect, he's comfortable with the categories, but not so much > the way it was laid out in this document. He just wants to see a core > protocol that is binding-agnostic, and a profile that defines use and > bindings of the protocol; Thinh agreed with the approach. Either > terminology is comfortable for him, and placing both into the same > document is fine. A conformance section, which is a requirement to > conform to OASIS rules, most sensically matches a profile, since > conformance to a protocol is a less meaningful concept. > > The issuer can now state which protocols it is capable of using. If > it suggests a non-SAML protocol such as SPML or OpenID to subsequently > pass the data, omitted is how they would handle the use of different > types of identifiers. But Scott observed that SAML does not have a > fixed set of identifiers; it has a structure to allow you to use any > type of identifier you would like, and that should suffice to handle > this aspect of the multi-protocol use case. > > Tom Zeller submitted some questions to the list about this tonight > regarding clarification of the differences between a ManageNameID > request and a RetireSubject in the Notify protocol. > > Frederick was a little confused as to why PoCo was included, since > there is relatively little protocol included in PoCo. The idea, put > forth by Salesforce.com, was that a notification could be sent using > ChangeNotify. They wanted to use PoCo as the payload for a large bulk > transfer, and would "secure the channel and do whatever." Phil > expresses no opinion about how this next step is performed, > considering it out of scope for this proposal. The same is true for > LDAPv3, SPML, etc.; the notification is the only part that SAML is > responsible for if SAML is not the transfer protocol. It is a purely > informative reference and does not affect the SAML operations, and as > such the references are non-normative. > > In section 2.5.1, if the Notify Issuer indicates that many protocols > are available, a question was outstanding whether there should be a > way to indicate preference, e.g. through another attribute or an > ordering of the URI's. The other way to do this would be through the > SLA. Scott suggested text indicating that, in the absence of > out-of-band information, the order in the element SHOULD be taken as > preference. > > It should be clarified that a response will use one protocol, as the > alternatives allowing for the use of many protocols to respond to a > single ChangeNotify were too complicated to countenance. > > Scott will look at the schema for the next call. > > The next step for Phil will be to complete the profile section and to > move the examples into the profiles to give a cleaner separation. > There's a fair number of empty paragraphs left to do. Detailing how > an AuthnRequest works with a ChangeNotify, for example, is a goal. > This would differentiate between an ordinary AuthnRequest, and the > initiation of identity federation via presentation of an AuthnRequest. > > Thinh proposed another scenario where a ChangeNotify would lead to an > AuthnRequest that would suggest an identifier that could be used to > create a new identity at the recipient of the AuthnRequest, followed > by a ChangeNotify Response. Phil has some concerns about mixing the > protocols in such a way. Given the complaints and problems about > getting the user-agent to the providers in the right sequence at the > right time, Scott is dubious that such a mix can be performed well, > and a consensus was reached that a cleaner separation between the two, > rather than an encapsulation, would be a better approach. > > Scott suggested a Metadata section needs to be added to the document > as well. > >> (j) SOA-TEL Token Correlation Profile (Federico/TI) - any updates? > > Federico had no updates on the document itself. He analyzed the > specification again after Scott's comments regarding the applicability > of the delegation work to Federico's use case. > > Federico is still not sure whether the token correlation requirements > and semantics are sufficiently different from the delegation work. > He's also not sure whether the token correlation profile and syntax > are complete and correct. > > Some of the restrictions have been placed on Federico's company by > their vendor, due to limitations of the IdP implementation. It was > more comfortable sending two separate assertions. It also more simple > for them to implement the issuance of SAML assertions that are > generally usable at a number of services, rather than issuance of > specific assertions for every application, because the IdP requires > less knowledge of the business services. It's also nice to decouple > business policies from the actual technical implementation. > > He's still concerned about the processing of the expiration time of > the first SAML assertion, and whether and how to imbed the link from > the second assertion to the first assertion, particularly without > invalidating the signature on the assertion. Requiring that both > assertions be valid makes the profile a little simpler. > > Federico also thought it might be interesting to place the correlation > element out of the assertions themselves, and use it as an entirely > standalone token. > > Federico understands if this profile is not considered the best > approach within the SSTC on the basis that existing SAML > specifications could achieve his goals. > > Scott sees a subjective question and an objective issue. > > Subjectively, he thinks it's inappropriate to create a profile that > allows an RP to ignore the validity of one of the assertions. Nate > agreed. > > The objective issue with regards to this profile is there is no way to > use the condition that he's trying to create outside of the signed > content and keep it in the assertion. If the correlation condition is > not expressed in the assertion, then it's not in SAML, and needs to be > done somewhere else, such as WS-Security, where there are already ways > to chain multiple tokens to a single message, which may be a more > appropriate foundation. If you want to recycle elements of SAML in > another protocol or context, that's fine, but it's still not a SAML > issue. > > Federico explained that the WS-Security working group is on > maintenance status, so it's a difficult place to do further work. As > such, Nate suggested that Federico try this series of actions: > > 1) Analyze the delegation profile to see whether its semantics and > technical requirements can solve his use case. > 2) If not, make sure that token correlation can be expressed at the > assertion level, rather than at a message level, or outside the > assertion. The SSTC is not the right place for definition of message > level constructs. > 3) If token correlation can be expressed as a <Condition> in an > <Assertion>, and the requirement that both <Assertion>s be valid is > okay, then continuation of work on the Token Correlation Profile in > the SSTC is appropriate. > >> (k) Channel binding proposal -- Scott. > > Scott has been playing around with some strategies for incorporation > of the channel binding concept for pairing SAML to GSS or SASL. He's > come up with a way to allow the IdP to be a mediator for channel > binding negotiation, a cool little trick that can really improve the > phishing story. One very simple application of the material would be > to plug a MITM hole in the existing SOAP binding, where the SOAP > binding is often authenticated with the SOAP signature because client > TLS is more painful. From the people who have looked at it, some > consensus has arrived that it could be useful. > > He plans to move this along independently, but in parallel, will > produce a new version of the ECP that uses the channel bindings in > this proposal and also adds holder-of-key support. The presentation > of the profile would also be simplified so it would be less > confusing. This has a ways to go, but he wants to move this along > fairly quickly, in order to encourage a GSS proposal(at the IETF, > likely in KITTEN rather than the SASL working group) to move more > rapidly too. This will likely lead to some natural liaison work with > the SSTC. > >> (l) Metadata extension for Login/Discovery -- Scott. >> > > Scott hopes this document will speak for itself, and it has been > alluded to on a number of other calls. This is a specific proposal > from Sampo, he believes, to use the Organization elements in metadata > to include descriptions of IdP's and SP's and include logos. Back > then, individuals thought it distasteful to do it, but based on > experience and embedded base that have accrued since then, it seems > clear that the use case is important and some extensions are necessary > to address it. > > The extensions are in two subsets; one is for user interface, and the > other set of extensions relates to hinting information to allow > discovery tools to potentially derive guesses about the IdP to use, > particularly from client information, such as network address. Some > strawman implementations are being fiddled with right now, but the > standards process doesn't need to be rushed. > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- -------------------------------------- Anil Saldhana Leader, JBoss Security& Identity Management Red Hat Inc URL: http://jboss.org/jbosssecurity BLOG: http://anil-identity.blogspot.com ---------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]