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: Proposed Minutes for SSTC Telecon (Tue 6 Aug, 2013)


> 2. Need a volunteer to take minutes.

Nate volunteered.

> 3. Approval of minutes from previous meeting(s):
> 
>   - Minutes from SSTC Call on 23 July 2013:
> 
> https://lists.oasis-open.org/archives/security-services/201307/msg00036.html

Hal moved for the approval of the minutes and Scott seconded.  There were no objections and the minutes were adopted.

> 4. AIs & progress update on current work-items:
> 
>  (a) Current electronic ballots: None.
> 
>  (b) Status/notes regarding past ballots: None.
> 
>  (c) SAML 2.1 work (Chad)
>      - SAML2.1 wiki: 
>        https://wiki.oasis-open.org/security/SAML2Revision
> 
>      - Chad's list:
>        https://wiki.oasis-open.org/security/SAML21
> 
>      - Sample ToC for an SSO Profile:
>        https://wiki.oasis-open.org/security/SAML21ExampleProtocol

Chad was unable to join today's call and had no real update.  He's conveyed our decision to proceed with the multi-part document model to TC Admin.

>     - Open AI: Hal (whether to roll sec. considerations into
>        into core/profiles/bindings, or a separate doc.)

Hal thinks it would be reasonable to pick out the security considerations that are relevant to the content of other documents that define SAML and include pointers to them in those documents.  This would allow for countermeasures to be flagged inline and associated with the security consideration that merits that countermeasure.  This would be more helpful for implementers.

The only concern is that we may find ourselves repeating the same security considerations in different documents, but we'll find out how much there is.

We're comfortable maintaining a general security considerations document that gives background and some all-purpose advice, such as recommending the use of TLS.

There have also been new attacks designed against SAML since 2006, so revising the security considerations to cover those attacks and mitigations would be important.

We assume that responsibility for writing these security considerations would fall ultimately to Chad, but with SSTC assistance and input.

>  (d) Conceptual/overview of Metadata (Rainer Hoerbe)
>      - Further Steps thread. Any updates?

Rainer was unable to join this call and sends his regrets.

>  (e) XPA updates (Mohammad Jafari)
>     - Any updates?

The XSPA working groups are still working on the profiles and there was some unexpected work that came up, so the ultimate date that the specs are ready for the SSTC to review will likely be near the end of August rather than mid-August.

>  (f) SAML Token Profile for ebMS (Ian Otto / Australia)
>      - Any updates?
> 
> https://lists.oasis-open.org/archives/security-services/201307/msg00024.html

Stay tuned for a new draft coming that will incorporate some comments that Ian received, including some from the SSTC.

>  (g) SAML ECP (Scott)
>      - AI: Scott to request the CSD and ballot.

Scott is waiting on the CSD to be published.  He got validation that a red-line specification would be necessary to demonstrate that there were no substantive changes.  He's uploaded that red-line version.  He will follow up to see if the CSD is being created now, but he's not sure if this got lost in the inner workings of TC Admin.

Rob sent email to the list a few weeks ago about a problem in the AuthnContext schema.  Rob is curious how the committee intends to deal with that because they're in the process of defining some more context types themselves for a variety of methods and they'll consider bringing those back to the committee for further standardization if there's interest.

The schema doesn't preclude you from doing what Rob would like to do -- essentially, adding content in the restriction that it requires just to satisfy the restriction, then defining the actual information they want alongside the meaningless restriction.  That may not be the most logical approach, but it seems much more feasible than defining a new class or attempting to change the schema.

The alternative of creating a second class creates other headaches and it's not clear who would put in the time and energy needed to publish a second class.

The claim had been that you'd authenticate by the methods in the context, but that's turned out to not be practical as a concept.  Something could be defined for soft tokens, for example, but then there still needs to be a way to compare those to hard tokens.  The fewer methods that you define the easier this is to do within a community.  In some communities, the view is that we should talk about deployments and assurance rather than specific technologies used for simplicity.  Defining a set of universal relationships between these methods would be a great challenge.

Scott's not sure how to get there from here.  In 2.1, we could add more classes if we want, but that's just adding more meaningless strings that people don't make use of because you can't enumerate any possible approach.  Deployments do care about distinctions between authentication contexts, but we can't create a universal set of distinctions that are universally cared about and define it for the world.

From a spec standpoint, being able to simply define a class and say that a class is a deployment-specific identifier that identifies some appropriate set of deployment related techniques were followed would be nice.

Extending existing classes didn't work well for Rob but Scott thinks that never really worked well as a concept.  These authentication classes didn't have intentional relationships between one another, with subclasses of other classes.  If they're defining a new class, it has nothing to do with existing classes and there would be no reason to recycle an existing class schema in some other way.

Hal thinks it's fine to say that my organization has A, B, and C, and your organization has 1, 2, 3, and that's okay until everyone has to map A B C 1 2 3 to concepts within their own deployments.  It's much more appealing to a vendor to be able to define a handful of strings that deployers could use but Scott doesn't think general context definitions and comparisons between them is a solveable problem.

For the problem that Rob is dealing with today, if they're defining a class, it's not one of the existing values and it has no defined relationship to those existing values and no software can or should assume anything about that relationship; that relationship needs to be deployment-time configuration, which rarely gets done, but that's more evidence about the limited use and usefulness of these classes in many deployments.

The end solution may be defining a new time sync token schema and be done with it.  Adding new classes may be an implementation issue but it's not a problem from a specification point of view because the multiple classes just have nothing to do with one another.

It would be theoretically possible to deprecate the old class and define a new class that has the bug fixed, but if Scott were planning on doing something, he'd want to try to get rid of the entire mess without breaking anything.  Scott would love to deprecate the schema and deprecate declarations completely in SAML 2.1, leaving just the opaque context references.

Thomas thinks that the deprecation path seems like the most promising option and he'd like to continue the discussion of this to understand the magnitude of any community that may be impacted.  Hal doesn't see the value of deprecation, especially because the purpose of 2.1 is primarily to better document how to use SAML without having a major impact on interoperability.  Hal sees a difference between discouraging use of fields and the possibility that the fields would be removed from the specification in the future.

We ran out of time discussing this on the call and will put it on next call's agenda.

> 7. Next SSTC Call:
>   - Tuesday 20 August 2013.

We look forward to speaking with you then.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]