OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

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


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


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.



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