RE: [wss] HMAC Key Derivation in UsernameToken Profile Issue

[Jerry Schwarz <jerry.schwarz@oracle.com>]

At 09:22 AM 1/12/2004, Blake Dournaee wrote:
>Toshi -
>
>If we have all agreed that the UsernameToken profile is pushing key
>derivation out of scope, we should make this clear as well.
>
>How about something like this:
>
>"When a UsernameToken is referenced from a <ds:KeyInfo> element, it can
>be used to derive a key for a message authentication algorithm using the
>password. This profile considers specific mechanisms for key derivation
>to be out of scope. Implementations should agree on a key derivation
>algorithm in order to be interoperable."

I assume you're proposing this for the UsernameToken profile in which case 
I think it is more accurate to say

"The use of a UsernameToken referenced from a <ds:KeyInfo> is not a part of 
this profile. Messages that include such a use do not conform to this 
version of the profile."


>Blake Dournaee
>Senior Security Architect
>Sarvega, Inc.
>http://www.sarvega.com/
>
>
>
>
>-----Original Message-----
>From: NISHIMURA Toshihiro [mailto:nishimura.toshi@jp.fujitsu.com]
>Sent: Friday, January 09, 2004 7:00 PM
>To: wss@lists.oasis-open.org
>Subject: Re: [wss] HMAC Key Derivation in UsernameToken Profile Issue
>
>Blake,
>
>I agree. Something should be mentioned about key derivation.
>
>Section 7.1 of the core spec says about <wsse:SecurityTokenReference>
>element as follows and our current discussion is about this case:
>| This element can be used as a direct child of <ds:KeyInfo> to
>| indicate a hint to retrieve the key information from a security
>| token placed somewhere else.
>
>So, how about including sentenses such as:
>   When a UsernameToken is referenced from <ds:KeyInfo> element,
>   it can be used to derive a key. The detail will be specified
>   elsewhere.
>   (Please give us better English wording!)
>in Section 3.2 of UsernameToken profile?
>
>
>
>Now, I wonder about other tokens:
>   When SAML Token is references from <ds:KeyInfo>, what does it mean?
>   Should we say something about it in SAML Token profile?
>
>
>---
>Toshi
>
>
>At Fri, 09 Jan 2004 10:43:12 -0800,
>Blake Dournaee wrote:
> > All,
> >
> > This comment by Srinivas echoes my sentiments exactly. We should say
> > something about key derivation for the Username Profile, even if it is
> > to say that it is specified elsewhere. Not all developers may be
> > familiar with the WS-I BSP at first and this issue is a major
> > interoperability stumbling block if left open.
> >
> > Blake Dournaee
> > Senior Security Architect
> > Sarvega, Inc.
> > http://www.sarvega.com/
> >
> >
> > -----Original Message-----
> > From: Srinivas, Davanum M [mailto:Davanum.Srinivas@ca.com]
> > Sent: Friday, January 09, 2004 5:05 AM
> > To: Anthony Nadalin; wss@lists.oasis-open.org
> > Subject: RE: [wss] HMAC Key Derivation in UsernameToken Profile Issue
> >
> > Anthony, Team,
> >
> > My 2 cents...We should address this issue in WSS-TC as there is
>already
> > a precedent (WSE 2.0 Tech Preview) and is one of the first stumbling
> > blocks a customer would face when doing an interop. A customer will
>find
> > that 2 toolkits claiming to support the same version of the WSS spec
>and
> > profiles from OASIS will NOT work out of the box and the customer will
> > find out that he needs to request information from the Vendors about
>not
> > just WSS spec compliance, but also WS-I BSP compliance which will
>reduce
> > the importance of this spec.
> >
> > thanks,
> > dims
> >
> > PS: FYI, i ran into this in may of last year, see attached email on
>how
> > difficult it was to get details if the spec is not complete.
> >
> >   _____
> >
> > From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
> > Sent: Thursday, January 08, 2004 9:12 PM
> > To: wss@lists.oasis-open.org
> > Subject: RE: [wss] HMAC Key Derivation in UsernameToken Profile Issue
> > > What do others think? I still feel strongly that this issue is a
>bane
> > on interoperability for the Username Token profile.
> >
> > It seems like this would be best handled by the WS-I BSP since there
>are
> > many different mechanisms that could be used. Now is the prime time
> > to bring this up since we are in early phase of the BSP.
> >
> > Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
>
>To unsubscribe from this mailing list (and be removed from the roster of
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup
>.php.
>
>
>To unsubscribe from this mailing list (and be removed from the roster of 
>the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.