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

RE: Anonymous IKE phase 1 -mode

It would be very useful to authenticate the server only, keeping the client
user or machine ID anonymous, ala normal HTTPS usage of SSL (without client
auth).  Does anyone remember why this wasn't provided in IKE ?  I read
through the Jan 99 SSL vs. IPSec and Vital's portable client credential
comments way back, but haven't seen the reasons why IKE didn't provide a
mode for this.  -Wm

-----Original Message-----
From: Tamir Zegman [mailto:zegman@checkpoint.com]
Sent: Monday, November 22, 1999 11:55 PM
To: Ari Huttunen
Cc: ipsec-list
Subject: Re: Anonymous IKE phase 1 -mode


Hi Ari,
See my comments below:

Ari Huttunen wrote:

> Somehow I have a feeling this idea will be shot dead, but
> I think there's some good to be had by it, so I'll give
> it a try...
>
> Basically the problem is that traditional Internet communications
> have been based on "authentication by IP addresses". This has
> one good quality (only) that I can think of: it is available to
> absolutely everyone in the Internet. IKE requires more, which
> means that it's not available to absolutely everyone. This in turn
> means that you can't encrypt your communications with that sort
> of a peer either. This in turn helps things like ECHELON.
>
> If there existed an IKE phase 1 mode that would not do any more
> authentication than what is provided by IP addresses, all Internet
> communications could become encrypted at once. This would make
> large scale Internet surveillance like ECHELON harder, because
> passive surveillance would no longer work, and active methods
> would be necessary.
>
> Now, I've created an IKE authentication method that was inspired
> by CRACK and SSH, and which works as follows:
>
>    Initiator                       Responder
>   -----------                     -----------
>    HDR, SAi, Ni
>                           --->
>                           <---     HDR, SAr, Nr
>    HDR, KEi, PKi, SIGi
>                           --->
>                           <---     HDR, KEr, PKr, SIGr
>
> (The signatures sign every field sent by that entity
> previously in the protocol as well as the source and
> destination IP addresses. PKx = Public Key of entity x.)
>

Signing IP addresses is NAT unfriendly.
If SIGi does not include Nr then Responder is opened to the following DoS
attack:
A and B perform this exchange.
C records the packets from A.
C then later replays these packets.

>
> This protocol has these properties:
> - After these messages I and R know they have a secure
>   channel to someone holding the private key corresponding
>   to the received public key. This someone is capable of sending
>   and receiving packets with the correct IP address.
> - Resistance to DoS attacks: The initiator has to perform a signature
>   calculation before the responder responds with KEr or SIGr.

Of course, the responder still needs to do signature verification.
Assuming you are using RSA, since the exponent is usually 3 or 65537 this
is not a problem.
However, a DoS attacker can simply select a different (larger) exponent.
So in order to protect herself from a DoS the responder needs to limit
the size of the initiator public key exponent.

>
> - Identity protection is provided. Even more protection
>   is possible by changing the IP address and the public key
>   in every session.
> - There's no protection against man-in-the-middle.
>

Yep.

>
> ps. If this idea is rejected by US persons, we can always raise
>     conspiracy theories... ;-)
>
> --
> Ari Huttunen                   phone: +358 9 859 900
> Senior Software Engineer       fax  : +358 9 8599 0452
>
> Data Fellows Corporation       http://www.DataFellows.com
>
> F-Secure products: Integrated Solutions for Enterprise Security

Tamir.
Follow-Ups: