[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Which comes first?
Marc,
> > "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.
Well since PF_KEYv2 is not an IPSec draft and the authors of PF_KEYv2 chose
to define their own monolithic, one-dimensional number space instead of
using IPSec-approved DOI values (and including a DOI-type field in the
sadb_sa struct to multiplex things like IPSec and RIPv2 in exactly the same
manner that ISAKMP can) and since they chose to impose unnecessary
restrictions on the behavior of ISAKMP/Oakley I'd like to know why PF_KEYv2
implementations (still haven't seen one yet) should have _any_ impact on
IPSec documents.
> 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 you're talking about where to slice-and-dice I can honestly tell you
that mine is the One True Religion and yours is heretical. If you're
talking about where the text should go then since ESP does both auth and
encrypt it would make sense to inform the implementor right there about
what goes first without having to context switch to another document-- it's
hard enough jumping from document to document as it is. Nothing in that text
suggests that slicing-and-dicing must be done in any particular place. It
merely states that when slicing-and-dicing to take the encryption key first.
If a PF_KEYv2 implementation (or I should say a KM protocol that has been
hacked into PF_KEYv2) does not do this then it won't interoperate with
non-PF_KEYv2 (i.e. every single one out there already) implementations.
Yes, Ted, this is what all interoperable implementations have been doing.
Dan.
Follow-Ups:
References: