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

["Blake Dournaee" <blake@sarvega.com>]

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."

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.