[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]