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 (14 June 2011) + NEW ACCESS CODE


1. Roll Call & Agenda Review.

Quorum was achieved.

2. Need a volunteer to take minutes.

Nate volunteered.

3. Approval of minutes from last meetings:

- Minutes from SSTC Call on 31 May 2011:


Hal moved to approve the minutes, and Nate seconded.  No objections were raised and the minutes were approved.

4. AIs & progress update on current work-items:

 (a) Current electronic ballots: 3 Kerberos docs.

 (b) Status/notes regarding past ballots: (none).

There are three Kerberos documents: attributes, subject confirmation, and a web browser SSO profile all with open ballots.  Thomas requested that all participants find the time to examine the documents and vote.

 (c) Session Token Profile (Hal)
     - Status: New CSD requested May 16.
     - Status: CSD Creation request is still in TC-Admin Queue (#496).

Hal received numerous reports that this is in progress, but now Chet is on vacation.  The CSD has not yet been created, so no public review or ballot can be created yet.

 (d) Attribute Predicate Profile (Gregory/Franz-Stefan)
     - Status: WD01 uploaded May 16.
     - Any updates?

Franz-Stefan wanted to respond to the comments received on the May 17 calls from Scott.  He didn't see references to the attribute query profile, and he suggested the protocol section be reworked.  It wasn't clear to him what the distinction between protocol and profile was, and after reviewing other existing SSTC documents, it's more clear to him what the distinction is.

The document will need to be restructured.  Franz-Stefan is particularly inspired by the Change Notify profile, and he wants to move the element and type specifications to a protocol section.  They also intend to include subsections describing processing rules explicitly.

The entire document may also be renamed from "Attribute Predicate Profile" to "Attribute Predicate Protocol", again inspired by Change Notify.  Nobody had any strong feelings about the formal title of the document, so this renaming will occur alongside the document restructuring.

Franz-Stefan does need to discuss how to write a binding section, but intends to follow the same approach as Change Notify to simply state that they intend to use the same bindings as core.  But Scott thinks there needs to be more detail because there is a very large number of bindings in core.  In order to get interoperability, Scott recommended creating a virtual duplicate of the original query profile to have a resultant profile that is both interoperable and compatible with existing code.  Message formats and semantics need to be solidified, and the exact set of bindings that need to be supported and how they need to be supported is required.  The protocol doesn't care, but the profile has to.

The conformance section should be used to guarantee desired interoperability; this is why bindings have to be specified somewhere.  It can also be used to discuss relevance to other, outstanding profiles.  Most profiles in the core specification are orthogonal to Attribute Predicate, so they will likely not be mentioned at all.

Franz-Stefan will examine the existing profile, protocols, and conformance for the attribute query profile and try to reflect that in his draft.  If he has troubles, he will mail Scott directly.

 (e) Kerberos profiles: [Josh/Thomas]
     - Status: Web broser SSO profile already CD01 (ie. CSD).
     - Status: Subject Confirmation profile already CD01 (ie. CSD).
     - Status: CS Ballots created for the 3 Kerberos docs

Thomas again requested a vote on these long due documents.

 (f) Change Notify Protocol Version 1.0 (Thinh/Phil)
     - Status: Request submitted for 15-day CSD Public Review


The 15-day CSD request had been submitted, and his understanding from TC Admin is that it will be posted near the end of this week or next week.

 (g) Channel binding proposal (Scott)
     - Status: awaiting other items in other groups.
     - Any updates?

No updates.

 (h) Enhanced Client or Proxy Profile (Scott)
     - Status: WD02 uploaded last week.
     - Status: work waiting for items in IETF Kitten WG.
     - Any updates?

Also no updates.

 (i) Metadata Extensions for Documentation/Registration (Chad)
     - Status: WD05 uploaded 21 March 2011.
     - Status: CSD01 specification has been posted.
     - AI: Since spec needs correction, back to WD again.
     - AI: Want to ask for CSD.

Similarly, no updates.  There will be a new working draft at the end of this week and Chad will ask for a CSD creation request vote on the next call.

 (j) Errata document (Scott):
     - Any other updates?

SECURITY-12 was created.  A paper was released this month analyzing a security flaw in SAML that can be considered a flaw in any redirection-based SSO protocol, including OAuth, OpenID, or anything else that relies on a simple browser.  Some of the language in the paper was softened as a result of Scott's comments, but he still thinks the analysis was too harsh.  He believes other vendors had been looped in as well.

Scott had been asked to try to help them make improvements to the spec in a few areas that would help implementors avoid common mistakes that had been often made in implementations they had experimented with.  He did so to some degree.  They had requested a major revamp of the security considerations document as a result of this errata, but Scott doesn't have the time to do this, and the guidance is also more for deployers than implementors.  While admirable, that may be outside the scope of what formal specification documents should discuss.  If the researchers were prepared to participate in the SSTC and dedicate some time towards this writing, the SSTC would be appreciative.

The major bug they found in many implementations was where there was no check of the RelayState parameter, allowing it to contain arbitrary URL's.  The errata suggests changes to several documents where RelayState is defined.  Scott also came up with a few potential additions to the front-channel SSO profiles that are vulnerable as well.  Placing something in the actual profile to discuss the problem is helpful because many implementors start there and read backwards.  As a result, there may be an entire new section in the original Web Browser SSO profile to call out the RelayState issue specifically.

Channel binding for ECP may mitigate the threat as well, but Scott's not sure.  With capable clients, there is sufficient protection that SAML is able to afford.

The errata is very important; many implementations got this wrong, and that's a sign that some text is missing from the specification itself.  Both the IdP and SP do need to be careful, but Scott's text is more targeted at the SP, and that could be clarified some as well.

This doesn't fix the issue in the paper; the issue in the paper is essentially unfixable without modifications to a browser.  He'd like people to read the text of the proposal and we may be able to adopt it in the next call.

His biggest complaint is that the paper neglects to realize that all the protections they suggest will make IdP-initiated SSO impossible.  This is a mandatory feature in the original specification, and it is widely used.  Hardening the SP against the attacks described in the paper would require tracking state across the front and back of the exchange, and there is no state at the front of the exchange if it is IdP-initiated.  Some other suggested fixes like client certificates in browsers, even self-signed, were considered impractical for wide-scale deployment.

If support for IdP-initiated SSO was a mistake, there's not much that can be done about such a mandatory requirement in an errata, but other recommendations can be made, such as that deployments should have a feature allowing for IdP-initiated SSO to be disabled.

Scott will tweak the SECURITY-12 text a little further, but most of the meat is already there, and SSTC members are highly encouraged to read it and ensure that it is acceptable.

It's unclear how much attention this research will receive.  It may be productive for the SSTC to issue a formal response at some point, as well.

5. Assorted mail items:

6. Other items:

7. Next SSTC Call:
  - Tue 28 June 2011.

We look forward to talking to you then!

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