[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ISAKMP null transforms



Brett,

>>I don't see the problem here. If you don't want to do AH you shouldn't worry
>>about your peer getting any message about your ability to do it. The only
>>thing your peer cares about is what you intend on doing-- how you intend
>>on communicating.
>
>Well, I'm not sure I agree.  When I send a list of transforms in some
>order, I implicitly state both a list of capabilities (all members
>on the list) and an ordering of preferences.  Not "wanting" to do
>AH doesn't imply that I'm not "willing" to do it should my peer deem
>it necessary.  I would like to say "I'd prefer no AH, but here's
>what I'll accept in order of preference: blah blah".

Ok. You don't want to do AH. I assume you want to do something though or 
else why go through the motions. So, let's say you want to do ESP without
AH (a bad idea, but for the sake of discussion, let's say that you do).
To do this you send a proposal for esp transform of "RFC-1829" followed by 
a proposal for esp transform of "DES-CBC-HMAC-replay". If the receiver's 
local policy accepts unauthenticated but encrypted packets he'll accept 
the 1st-- your preferred transform. If he doesn't, he'll accept the 2nd-- 
your "rather not but will..." transform. The implicit order of preference 
can be used to tell the receiver what you'd like to do, what you'll settle 
for, and what is a last resort, or any other graduation you can think of.

>>  The second phase of negotiation establishes security associations. There is
>>no such thing as a "null" security association. You can't do AH with nothing,
>>same for ESP.
>>
>
>True, but I'm suggesting that an accepted "null" AH proposal would be
>identical to accepting a proposal with no AH.

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.



References: