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

Re: IPSEC Security Gateways & NAT




----- Original Message -----
From: "Derek Atkins" <warlord@mit.edu>
>
> > This is a very good point! In pre-shared key based
> > authentication, there is no reason that the authentication
> > must wait until the DH related work is done. Authenticating
> > prior to DH can potentially make the IKE even more
> > resistant to DoS attacks under pre-shared key. Already the
> > anti-clogging cookies ensures that the attacker must perform
> > almost equal amount of work until message 4. With source
> > authentication before DH, we need not perform the work that
> > is necessary to process message 5.... if the source is not
> > authenticated.
>
> However in order for pre-shared key to work as you suggest
> (authentication before DH) you have to know a-priori the ID of your
> peer in order to perform the authentication.  This implies that
> either:
> a) you have to deny ID protection and send IDs in
>    the clear early in the protocol, or
> b) you have use IP Addresses as names.
>

I was talking about IKE and not IKE in presence of NAT.
I have pointed out to you earlier that IKE does not work
for pre-shared keys in main mode and ESPoUDP does
not fix it. That e-mail is included at the bottom.

Back to IKE in absence of NAT, standard practice in
pre-shared key base authentication is  to use IP addresses
as names. The suggestion was to make it more robust to
DoS attacks by authenticating before DH.

> You cannot use IP Addresses as names when traversing NAT, because the
> IP Address is going to be changed by the NAT gateway to an unknown
> address.  So, you either have to send IDs in the clear, or you have to
> perform the DH first.
>

see earlier comment.

> Note than an attacking initiator need not request pre-shared keys in
> order to mount a DDoS attack against a responder.  Other
> authentication means are just as susceptible.
>

Right! The point is that pre-shared keys based authentication
can be made more robust against DoS attacks compared to
the other three authentication methods. In their current form,
all authencitation methods are susceptible to DoS attacks.

regards,
Jayant

----------------------------------------------------------------------------
---
> ----- Original Message -----
> From: "Derek Atkins" <warlord@mit.edu>

Ok, yes, there is a problem with using pre-shared keys in main mode.

-derek

"jshukla" <jshukla@earthlink.net> writes:

> ----- Original Message -----
> From: "Derek Atkins" <warlord@mit.edu>
> > > HASH_I = pfr(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b)
> >
> > Um, I don't see anything here that necessarily depends upon the IP
> > Address of either Initiator or Responder.  Perhaps I am being dense,
> > but could you please point out the specific term to which you refer?
> > Keep in mind that the ID term is **NOT** necessarily tied to the IP
> > Address, as you can use many types of ID (such as FQDN) that are
> > "movable".
> >
>
> Isn't there a problem in using pre-shared keys for authentication in
> the main mode? The responder uses the IP address to look up the
> pre-shared key. Because of NAT, it may not be able to look up the
> correct pre-shared key?! If you use aggressive mode, you can overcome
> this problem, but the authors of ESPinUSP proposal use the main
> mode in their example.
>
> regards,
> Jayant
>
>


Follow-Ups: References: