Re: FW: [wss] HMAC Key Derivation in UsernameToken Profile

[NISHIMURA Toshihiro <nishimura.toshi@jp.fujitsu.com>]

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.
> 
>