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: Proposed Agenda for SSTC Call (10 August 2010)



> 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 27 July 2010:
> http://www.oasis-open.org/apps/org/workgroup/security/email/archives/201008/msg00009.html
The approval of the minutes was delayed until the following call due to 
errata in the attendee list.
> 4. AIs&  progress update on current work-items:
>
>    (a) Current electronic ballots: HOK Web Browser SSO. Please vote.
The ballot has closed with 10 of 12 votes in favor and none against.  
The approval of the Holder-of-Key Web Browser SSO Profile as Committee 
Specification was succeesful.
>    (d)  SAML V2.0 Holder-of-Key Assertion Profile Version 1.0
>         - Status: CS-01 version of this doc is on WiKi.
>         - Status: Thomas to ask Mary.
Thomas has not done this yet, so the action item remains outstanding.
>    (e) Kerberos related items. [Josh/Thomas]
>          - Kerberos Attribute Profile:
>          - Status: Public review period closed on 15 June 2010.
>          - Status: CMU Use-case discussions (sent to security-comments list).
>          - AI: Josh/Thomas will suggest additions to Attribute Profile.
Thomas, Josh, Scott, and Jeff from CMU have been discussing over email 
how to amend the attribute profile.  CMU would like to be able to send a 
decrypted KRB_CRED blob from a KDC in an assertion and deliver it from 
an IdP to an SP.  The API exists, but RFC 4120 may prohibit this 
implicitly because KRB_CREDs should not be sent around in plaintext.

The other trouble may lie in the cipher suite used.  The IdP and SP do 
have a public keypair that can be used to negotiate an encryption 
method, but in XML encryption, the actual data would be encrypted with 
the key using XML encryption, but in this case the data would be 
encrypted as specified by Kerberos (ASN.1?) and the algorithm types and 
other pieces of information may not align with the cipher suites as 
named by Kerberos.  The mapping of algorithms from XML encryption to 
Kerberos cipher suites is likely to be pretty obvious and easy to 
profile, and Scott isn't suggesting some sort of new protocol be invented.

Because confidentiality and security are handled by the SAML layer, it's 
not entirely important to have the encryption at the Kerberos level, but 
they would like to be compliant with the RFC.  Scott would also like to 
allow for an encrypted use case anyway, so he would like to include 
something, but he doesn't exactly know what do to for that.  Further 
input from CMU is being awaited.

Thomas and Josh will provide an update and expanded edition of the 
Attribute Profile and circulate it to Scott and CMU to determine whether 
it's acceptable.  The cipher suite and encryption issues may be beyond 
the scope of the Attribute Profile itself.

>    (f) SAML V2.0 Identity Assurance Profiles, Version 1.0
>          - Status: Public review period closed on 13 June 2010.
>          - Status: Awaiting comments/resolutions.

Scott believes that necessary revisions have been made and would like to 
have this voted to 15 day public review.  The feedback has been 
responded to, so we should be ready to move to CD.

http://wiki.oasis-open.org/security/SAML2IDAssuranceProfile

Paul moved that we approve WD-02 to CD status and move it to a 15 day 
public review.  Nate seconds the motion, and there were no objections.  
Paul will do the CD edit and update the Wiki, and Thomas will submit the 
public review package.

>    (g) NSN Attribute Management proposal (Thinh/Phil) - any updates?

Phil has no updates from his perspective on the proposal, but continues 
to encourage people to read the document.  He is also happy to address 
any background questions from individuals new to the proposal.  His next 
goal is to finish the profiles.

This is the fourth approach, now using notification messages, which he 
likes because it doesn't oblige SAML endpoints to do things.  He wants 
affirmation that others agree that the current proposal, relying on 
notification messages, is the proper approach.

http://www.oasis-open.org/committees/document.php?document_id=38737&wg_abbrev=security

Chuck Mortimore from Salesforce found it useful to perform this 
notification in the SAML context, but believes that change propagation 
might be performed using another protocol.  Part of the proposal(section 
2.4) involves the negotiation of the protocol that would then be used.  
For now, Phil will just profile the use of SAML for the change 
propagation, but he will allow others to profile additional protocols, 
such as STS, SPML, OpenID, PoCo, etc.

NSN has identified another use case that Phil would like to sort out.  
He thinks a normal AuthnRequest might be able to address the use case, 
but NSN disagrees.  Section 2.7 includes a comment discussing this use case.

>    (h) SSO initiation CD (Scott) - any updates?
Scott would like to take this document, along with the Algorithm Support 
CD, to 60 day public review, because he doesn't believe there are many 
other documents that will imminently need review as well.  He made the 
motion and John Bradley seconded, to no objections.  Thomas will handle 
the submission process.

http://wiki.oasis-open.org/security/RequestInitProtProf
http://wiki.oasis-open.org/security/SAML2MetadataAlgSupport

>    (i) SOA-TEL Token Correlation Profile  (Federico/TI) - any updates?
Federico was not on the call.
> 5. New work items:
>     - Project Moonshot (potential new work item)

The Moonshot BoF was held at the recent IETF meeting and a new mailing 
list has been established.  We anticipate that Josh will join an SSTC 
call in the near future to provide more introductory information, and 
draft documents are likely to follow.

A parallel item at the IETF, a pair of SAML SASL mechanisms being looked 
at in the Kitten working group, has led to discussion about how or 
whether to bring each forward.  One proposed by Cisco requires a web 
browser and one proposed by Scott uses a side channel.  There are also 
proposals for OAuth and OpenID.  The Kitten working group will need to 
resolve this pile of proposals and figure out what to carry forward to 
the IETF.  Scott also wants to look at how to add holder-of-key crypto 
to his proposal.

> 6. Related work items:
>     - SAML 2.0 Bearer Assertion Profile for OAuth 2.0 (IETF) - Brian Campbell.
This is another proposal that is unrelated to the SASL work that may be 
of interest to individuals who want to transport SAML tokens over 
OAuth.  Scott and Brian have disagreements and we would like to solicit 
input from other implementers who may have interest whether the draft is 
overly restrictive or a good simplification.
>     - IIW-East conference (in DC in September).

Details have been uploaded and registration started this week.

> 7. Propose an SSTC Face-to-Face meeting for September 2010:
>     - Awaiting for room confirmation.

Thomas will contact Jane, and then provide a poll using the OASIS ballot 
mechanism to see who is available to attend the OASIS conference itself, 
as well as to see who is interested in an SSTC face-to-face, possibly on 
given dates.



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