[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Which comes first?
Michael,
> >>Well, its not what any PF_KEYv2 person is implementing or has implemented
> ..
>
> Actually it is what some of us "PF_KEYv2 people" have implemented. The key
> daemon will supply exactly what is asked for. The kernel asks for 192 bits
> of encryption key and 0 bits of authentication key and gets just that. Of
> course if the kernel wanted to ask for 64 bits for ESP and 128 for the HMAC
> and KNEW a priori that the key daemon understood the ESP transform in use
> it could do so.
>
> Since the key daemon shouldn't have to know anything about the transform in
> use the kernel can decide how to cut up the keying material and ask for all
> the bits at once. PF_KEY doesn't preclude this.
Fine. I guess you can use PF_KEYv2 that way, if you wish. Its a
question for another forum to work out PF_KEYv2 inter-vendor
portability or API issues, if thats ever appropriate as the work
developes. (Personally I always interpreted "encrypt" or "auth" in
PF_KEYv2 to refer to the encryption algorithm or authentication
algorithms, not ESP vs. AH.)
Thanks for the tidbit, I shouldn't have presumed how different folks
made use of the PF_KEYv2 specification and should merely have said that
the PF_KEYv2 specification had separate delineation of authentication
vs. encryption keying material for passing down keying material. And
its certainly possible that other non-PF_KEY implementations have only
that separation.
Given this, would you (or anyone) have any trouble with my last suggestion
on Karen's text:
> ... 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 --