KEY(n) -> KEYMAT in Security Associations (06-369r4)
Ralph Weber
roweber at IEEE.org
Sun Sep 17 12:32:43 PDT 2006
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
David,
What would be the maximum size of KEYMAT?
For example, can I assume that one pass through a KDF cannot
generate more than 10 keys? Thus, 10 * (largest key size)
would be the max KEYMAT bit string (i.e., (10 * 512) / 8
equals a max KEYMAT byte size of 640).
All the best,
.Ralph
Black_David at emc.com wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Black_David at emc.com
> *
> The original work that lead to the KEY(n) element in security
> associations was based on a design assumption that all keys and
> the hash output size would be the same, namely 256 bits. Based
> on comments in the CAP meeting, that's now clearly an overly
> restrictive design assumption, so the array of keys [KEY(n)
> element] in a security association should be changed to a
> keying material bitstring [KEYMAT]. The consumer/user of the
> keying material would specify how much is needed, and the KDF
> produces the result (rounded up according to what the KDF can
> do). This is the approach used in IKEv2 (RFC 4306, Section
> 2.17) and is consistent with the NIST KDF that is specified in
> 06-369r4. This change should be made.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA 01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> black_david at emc.com Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10
mailing list