[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ISAKMP null transforms
Dan,
>Why obfuscate things with a "null" proposal? You don't want AH, then don't
>put it in the proposal. Or do you see some distinction between a proposal
>without AH and a proposal with a "null AH" specified? As a receiver, should
>I view those two differently?
>
> Dan.
Yes you can treat them differently since the "null" proposal *allows*
you to follow with a second and third choice for AH; the proposal
without AH does not. For example, I propose, in order:
"null", HMAC-MD5, HMAC-SHA
The receiver knows that I'd prefer no AH, but if it *requires* an
authentication header, at least it now has the option of choosing
ones I support; in the "without AH" proposal it does not since I
cannot tell it which I support.
Maybe my example would have been better flipped around. My security
policy demands that I support authentication, but not confidentiality.
I will, however, gladly support ESP transforms should my peer require
it. I propose:
AH: HMAC-MD5
ESP: "null", rfc1829, rfc1851
...again, my partner may choose to accept "no ESP transform", or choose
confidentiality with DES-CBC or triple-DES since I offered them. Note
that I am not including a "null" here for AH, since I am not willing
to offer that option as dictated by my policy.
Cheers!
Brett