[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.
> 

It is good to note that the issue came up earlier and was discussed, 
even though I dont like the alternative you suggest. In order to not expose 
the actual identities, the vendors would have to agree on an out-of-band
encryption by which to encrypt the ID in the vendor specific ID_KEY_ID.
This is yet another encryption, and yet another out-of-band requirement
in addition to the pre-shared key. Also, as Bryan pointed out, it
is a layer violation in that a pre-shared key has to be assusmed based 
on the src address (in IP header) rather than ID payload.

As an aside, can someone explain to me why SKEYID is evaluated differently
based on different authentication schemes used? Why couldnt they all be
evaluated the same independent of the authentication scheme, as a function 
of Ni_b, Nr_b and g^xy.
   ex: SKEYID = prf (hash(Ni_b | Nr_b), g^xy)

Distinctions between authentication schemes could be restricted simply to 
thw way HASH_I and HASH_R are evaluated.
For example, HASH_I and HASH_R for the pre-shared key authentication
could have been evaluated differently from other authentications by 
concatenating the pre-shared key to the message argument (i.e., arg2) of 
the prf function. 

This approach would cover the case Bryan pointed out, without requiring 
any changes to the main mode protocol.

cheers,
suresh
Follow-Ups: