OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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

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]