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

[Peter Dapkus <pdapkus@bea.com>]

fwiw, in 1.1.2 of the core spec, Key Derivation is already listed as a
non-goal.  On the other hand, it also lists "authentication mechanisms"
as a non-goal, but that didn't prevent us from defining a couple of
those for UsernameTokens (shame we didn't do the same for X509).

It does seem late to introduce key derivation to the spec for the
inteorp reasons that Tony points out.   

Rather than trying to prevent vendors from extending username token in
reasonable ways or making weak statements about the scope of this spec,
I'd propose that we add text that describes the proper way of extending
username tokens:  e.g.  implementors wishing to extend username token
for other purpose (i.e. key deriviation) MAY do so, but MUST define
child elements for UsernameToken which explicitly describe the
extension.  
  
from my point of view, the troubling thing in all of this is that it
sounds like several vendors have agreed on an implicit scheme for
deriving keys from username tokens -- there is no explicit information
about the key derivation mechanism in the soap messages that use it and
nothing to indicate that the processing of the security header requires
the use of proprietary extensions.

this seems problematic for a couple of reasons:  first, it's not a very
interoperable way to define a private extension -- for example, if
another vendor wanted to define a similar extension, there'd be no way
for someone to support both of these extensions;  second, I think its
confusing to end users trying to acheive interop that there's no
indication that extensions are required.

by requiring extensions be explicitly described in the token (or maybe
in the reference), we avoid these problems.  seems like we could add
requirements like these at this point since they don't affect interop of
the core spec or its profiles.

-Pete


On Mon, 2004-01-12 at 13:13, Blake Dournaee wrote:
> Jerry,
> 
> In my opinion, this statement is too broad. I can already argue that a
> 'use' of a UsernameToken *is* already part of the UsernameToken profile,
> for example, the token itself is used in computing a password digest,
> which is specified by the profile.
> 
> The restriction and clarification that I think is necessary refers to
> the HMAC key derivation. At the very least we need to say that any use
> of key derivation is out of scope.
> 
> Blake Dournaee
> Senior Security Architect
> Sarvega, Inc.
> http://www.sarvega.com/
> 
> -----Original Message-----
> From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com] 
> Sent: Monday, January 12, 2004 1:06 PM
> To: Blake Dournaee; 'NISHIMURA Toshihiro'; wss@lists.oasis-open.org
> Subject: RE: [wss] HMAC Key Derivation in UsernameToken Profile Issue
> 
> 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_workgrou
> p
> >.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_workgrou
> p.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.
> 
> 
> 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.
-- 
Peter Dapkus <pdapkus@bea.com>