[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
Quorum was achieved.
Nate volunteered.
Hal moved to approve the minutes, and Nate seconded. No objections were raised and the minutes were approved.
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.
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.
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.
Thomas again requested a vote on these long due documents.
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.
No updates.
Also no updates.
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.
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.
We look forward to talking to you then! |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]