[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Which comes first?
> Date: Tue, 16 Sep 97 3:39:05 EDT
> From: Karen Seo <kseo@bbn.com>
>
> "If both encryption and authentication services are selected,
> then the encryption key is taken from the first (left-most,
> high-order) bits and the authentication key is taken from the
> remaining bits. The number of bits for each is defined in the
> relevant transforms."
>
> This looks fine to me. Is it what most people have been implementing?
> I would have assumed so....
>
> - Ted
Well, its not what any PF_KEYv2 person is implementing or has implemented
at the kernel level where the authentication and encryption keys are
passed down in one message that clearly delineates the auth and encrypt
keys for the one ESP session.
The above text is fine in itself but I don't understand why this would
need to go into the ESP document which is a *auth/encrypt protocol*
specification (not a keying interface one) based on a set of transforms
which, in turn, specify keying material lengths of the individual
algorithms that can be used with ESP. Its an implementation issue how
the keys get to this ESP specification or code. The original question,
as I understood it, from Ben came up in the context of Key Management
and so this becomes an issue of how "Key Management vs. the ESP code"
needed to split the full blob of keying material from an ISAKMP/OAKLEY
context into the auth/encrypt portions. If we had a different KM
algorithm that negotiated independent blobs of material for
authentication and encryption then this issue may not even arise in
some implementations, the bits for each function may be clearly
delineated early on. Or if there's a manual key system that
independently specifies the MD5 and DES keys for a statically allocated
SPI splitting is again a moot point for ESP. Its clear.
Implementations of a KM and ESP should have the flexibility of either
one devying up a full blob of keying material into separate
authentication and encryption segment. We just need to agree on whats
needed for interoperation.
I would suggest Karen's text go into any key management related
document where a single blob of keying material is being passed around
so that the end entities can understand how to divide it up amongst
multiple algorithms. After all, these KM protocols did negotiate the
specific algorithms being used so this seems like a good place to
mention how to split the keys. Or, if people really feel this must go
into ESP, the above text should be pre-qualified with a "those ESP
implementations receiving a single injection of keying material from
KM for both auth/encrypt services divide it up as follows."
-- Marc --
Follow-Ups: