HMAC Key Derivation in UsernameToken Profile Issue

["Blake Dournaee" <blake@sarvega.com>]

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.