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

Re: Anonymous IKE phase 1 -mode



Ari Huttunen <Ari.Huttunen@datafellows.com> 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.)
>>
>>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.

Here's a comment on DoS resistance.
In your protocol, the responder must verify SIGi
before knowing whether the initiator really generated
the signature  SIGi or not.
This is not good in terms of CPU exhaustion.
As an alternative, please have a look at
http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt.
Thanks,

--^^--
Kanta


References: