Title: RE: [wss] Issue #282 - Pasword-based key derivation
Looks like the WS-Trust has the same problems as well
(Section 6 - http://www3.ca.com/Files/AssociationsAndStandardsBodies/ws_secureconv.pdf)
-- dims
From: Hal Lockhart [mailto:]
Sent: Sunday, June 13, 2004 10:42 PM
To: Srinivas, Davanum
M;
Subject: RE: [wss] Issue #282 -
Pasword-based key derivation
This
is one thing I looked at, but the process of establishing the labels seemed
rather nebulous and did not seem to add to the security, it did not distinguish
between key types, which enables a class of attacks and it lacks the
iteration feature, which adds to the effort of guessing
attacks.
Hal
-----Original Message-----
From: Srinivas, Davanum M
[mailto:]
Sent: Sunday, June 13, 2004 10:37
PM
To: Hal Lockhart;
Subject: 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:]
Sent:
Sun 6/13/2004 10:30 PM
To:
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.
