[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: HMAC Key Derivation in UsernameToken Profile Issue
Toshi - I agree with you that this is the same issue. I'm not sure, however, if it has been clearly resolved. At this point, the Username Token profile says nothing about how keys are derived from passwords. If key derivation is truly out of scope, it should be mentioned here. The way a password is mapped to a key is a major issue for username token interoperability. If it is out of scope, it should be clearly mentioned. Further, we should say that the mapping is defined, or should be defined, in a further profile. Regards, Blake Dournaee Senior Security Architect Sarvega, Inc. http://www.sarvega.com/ -----Original Message----- From: NISHIMURA Toshihiro [mailto:nishimura.toshi@jp.fujitsu.com] Sent: Wednesday, January 07, 2004 5:52 PM To: wss@lists.oasis-open.org Subject: Re: FW: [wss] HMAC Key Derivation in UsernameToken Profile Blake, Your issue is related to issue #128. http://lists.oasis-open.org/archives/wss/200307/msg00071.html Before draft 16 of SOAP Message Security, the example in 3.4 used <wsse:UsernameToken> to specify HMAC signing key. After draft 17, the example has changed to use a custom token, <xxx:CustomToken>, to specify HMAC signing key. I don't remenber the discussion about the issue #128, but I think HMAC key is currently out of scope for SOAP Message Security and UsenameToken Profile (and should be defined in other profile document). Toshi --- NISHIMURA Toshihiro (FAMILY Given) nishimura.toshi@jp.fujitsu.com XML/Web Services Technology Dept., STRATEGY AND TECHNOLOGY DIV., FUJITSU LIMITED At Wed, 07 Jan 2004 13:10:59 -0800, Blake Dournaee wrote: > > All, > > I would like to re-raise the issue below (HMAC Key Derivation Info) and > solicit more feedback from the group. This issue is causing real > interop. problems. > > I firmly believe we must place some sort of requirement that key > derivation information be conveyed if it is more than just the password. > The sentence that Rich suggested is a good start in my opinion. > > Regards, > > > Blake Dournaee > Senior Security Architect > Sarvega, Inc. > http://www.sarvega.com/ > > > -----Original Message----- > From: Blake Dournaee [mailto:blake@sarvega.com] > Sent: Friday, December 19, 2003 11:16 AM > To: 'Rich Salz' > Cc: wss@lists.oasis-open.org; speechu@sarvega.com > Subject: RE: [wss] HMAC Key Derivation in UsernameToken Profile > > Rich, > > I agree with you on this. There should be some sort of requirement that > key derivation information be conveyed. This should be a MUST and not a > SHOULD as you mention. > > Without this sentence requirement (or equivalent) we are in essence > creating the opportunity for two separate implementations of > WS-Security+UsernameToken to fully support the specifications, yet be > completely unusable together. > > What do others think about this issue? It is already causing some > interop problems in the field as implementers must try and reverse > engineer unspecified key-derivation algorithms in order to get username > tokens to work. > > Blake Dournaee > Senior Security Architect > Sarvega, Inc. > http://www.sarvega.com/ > > -----Original Message----- > From: Rich Salz [mailto:rsalz@datapower.com] > Sent: Tuesday, December 16, 2003 4:35 PM > To: Blake Dournaee > Cc: wss@lists.oasis-open.org; speechu@sarvega.com > Subject: Re: [wss] HMAC Key Derivation in UsernameToken Profile > > ... > > I suggest that we say something like "if the HMAC key is to be > derived from more than just the password, than implementations > MUST convey that information along with the initial shared secret." > I don't think it's right for us to outlaw any key derivation. That > kind of profiling should be left to WS-I. > /r$ > -- > Rich Salz Chief Security Architect > DataPower Technology http://www.datapower.com > XS40 XML Security Gateway http://www.datapower.com/products/xs40.html > XML Security Overview > http://www.datapower.com/xmldev/xmlsecurity.html > > > 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. > > > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]