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] Issue #282 - Pasword-based key derivation


Title: RE: [wss] Issue #282 - Pasword-based key derivation

In case we need "prior art" to compare with...here's the approach in WSE 2.0 Tech Preview:
http://www.dynamic-cast.com/mt-archives/000019.html

-- dims

-----Original Message-----
From:   Hal Lockhart [mailto:hlockhar@bea.com]
Sent:   Sun 6/13/2004 10:30 PM
To:     wss@lists.oasis-open.org
Cc:    
Subject:        [wss] Issue #282 - Pasword-based key derivation
This has taken more research than I expected. Rather than delay further, I will post an overview of my approach, which may gererate some discussion. I will follow this with proposed text.

Requirement

Starting from a password typed by a user or some other value derived from it, generate a key suitable for use in an HMAC or symmetric encryption algorithm.

Restrictions

Both parties must share the same secret.

The maximum key size generated under this scheme is 160 bits. Since a typical user password is the equivalent of only a 20-50 bit entropy source, this should not be an issue. (In other words, it makes no sense to use AES-256 when the key is derived from a password.)

Approach

This approach is based on (informational) RFC 2898, which is PKCS #5 v2.0.

Two new elements are added to the Password Token: salt and iteration. These are sent along with the username, instead of the password. Signature and encryption elements can indicate the use of the derived key by means of a direct (local URI) reference.

If key derivation is done, the salt must be present. The first octet of the salt contains hex 01 if the generated key is for an HMAC and hex 02 if the generated key is for encryption. All other values are reserved and MUST not be used. The next 120 bits of the salt should be chosen at random.

The iteration element is optional. If it is not present, its default value is 1000. If present a value of at least 1000 SHOULD be used.

The key derivation scheme is based on the one called PBKDF1 in RFC 2898. SHA-1 is used as the underlying hash function. In brief the salt is concatenated to the password and repeatedly hashed the number of times given by the iteration value. The output will always be 160 bits. Low order bits are discarded to produce the required key length for encryption, e.g. 128 for AES, 112 for 3DES, etc. The full 160 bits are used for HMAC functions.

Comments?

It would probably make sense to give the rationale for the key type, salt and iteration in the security considerations section.

Hal

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]