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

Re: More questions on ID types

On: Tue, 30 Jun 1998 16:19:32 EDT you wrote
> Bryan Gleeson writes:
[snip]
> > Thus perhaps it would be better for the Pre-Shared key case
> > to include the ID payload in the 3rd and 4th messages
> > of the exchange (the ones that transfer the D-H public info
> > and the nonces), rather than in the 5th and 6th. This removes
> > the need to look at source IP address at all, and would be
> > similar to the Authentication with Encryption exchange.
> 
> Unfortunately Pre-Shared-Key-Auth Main Mode would no longer be 
> an Identity Protect exchange if this change were made. 
> Protecting the identities of the parties is a notable feature 
> of Main Mode -- in contrast to Aggressive Mode -- for the 
> pre-shared key case. So I don't think Main Mode should be
> altered to send ID payloads in the clear.
> 
> I suppose there is some argument to be made for a compromise 
> mode in the pre-shared key case that would be more "aggressive"
> than Main Mode, but more "reserved" than Aggressive Mode.
> For example (illustrative purposes only):
> 
>               Initiator                        Responder
>              ----------                       -----------
>               HDR, SA             -->
>                                   <--    HDR, SA, KE, Nr
>        HDR, KE, Ni, IDii, HASH_I  -->
>                                   <--    HDR, IDir, HASH_R
> 
> This doesn't offer identity protection. But it allows 
> negotiation of the DH group (unlike Aggressive Mode) and 
> saves a full round-trip versus Main Mode. 
> (Other variations are possible. I haven't really considered 
> which ones might be better.)

  It also might open the responder to a denial-of-service attack since
he does an exponentiation before he's got any belief the he's talking
to a genuine, honest-to-goodness IKE peer and not a program that forges
thousands of "HDR, SA" messages per second from bogus source addresses.
Main Mode is not immune from such attacks but before the responder does
any real work he's got a strong belief that he's talking to a real entity.

  One of the nice things about Oakley (and also one of the things that made
it so hard to implement) is that it didn't have this problem. Each side
could send what it wanted when it wanted. The initiator could send an SA,
KE, nonce and the responder could only send a cookie, or a cookie and an
SA and a KE, or a cookie and an SA, or.... 

  A "reserved mode" (I like that) can be written up in a draft but Main
Mode is not changing at this point in time. Sorry Bryan but this point was
discussed about a year ago and the resolution is what you see today. If
you want to allow remote access with pre-shared keys use Aggressive Mode.
If you don't want to expose a meaningful identity use ID_KEY_ID as the
identity to which the pre-shared key is bound.

  Dan.
References: