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

[Peter Dapkus <pdapkus@bea.com>]

This sounds like a reasonable way to deal the question at hand (single
algorithm, well-defined parameters), tho I think usage attributes won't
be sufficient for all extensions (e.g. an extension that requires
parameters).   

Maybe we should identify the the general requirement (ie use of
extensions MUST be explicitly indicated in the token being extended or
in the reference to the token) and then describe a handful of mechanisms
for explicitly indicating the extension (mandate usage attribute, define
a child element and mandate its inclusion, etc.).

-Pete


On Mon, 2004-01-12 at 16:35, Jerry Schwarz wrote:
> I think the intention is to describe the use being made of a token in one 
> of the various usage attributes.  We created the problem you describe by 
> making this attribute optional rather than required. I think we already 
> have text saying what you want with regards to the usage attributes, but 
> perhaps it could be strengthened so that implementors realize that if 
> they're making proprietary uses of the defined tokens they should only do 
> so with their own usage attributes.
> 
> Put another way, proprietary profiles should always make usage attributes 
> mandatory.
> 
> At 04:03 PM 1/12/2004, Peter Dapkus wrote:
> >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>
-- 
Peter Dapkus <pdapkus@bea.com>