Re: [security-services] Proposed Minutes for SSTC Telecon (14 June2011) + NEW ACCESS CODE

[Anil Saldhana <Anil.Saldhana@redhat.com>]

On 06/14/2011 11:46 AM, Nate Klingenstein wrote:
>> AGENDA:
>>
>> 1. Roll Call & Agenda Review.
>
Voting Members
Franz-Stefan Preiss     IBM
Scott Cantor     Internet2
Nathan Klingenstein     Internet2
Chad La Joie     Internet2
Thomas Hardjono     M.I.T.
Frederick Hirsch     Nokia Corporation
Thinh Nguyenphu     Nokia Siemens Networks GmbH & Co. KG
Hal Lockhart     Oracle
Anil Saldhana     Red Hat

Quorum Achieved: 9 out of 13 voting members (69%)
Status: Gregory Neven (IBM) lost voting rights.

>> 2. Need a volunteer to take minutes.
>
> Nate volunteered.
>
>> 3. Approval of minutes from last meetings:
>>
>> - Minutes from SSTC Call on 31 May 2011:
>>
>> http://lists.oasis-open.org/archives/security-services/201105/msg00036.html
>
> 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
>>
>> http://www.oasis-open.org/apps/org/workgroup/security/email/archives/201106/msg00004.html
>
> 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.
>
> http://www.ai-lab.it/armando/pub/sec2011.pdf
>
> 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.
>
> http://tools.oasis-open.org/issues/browse/SECURITY-12
>
> 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!