Re: Do ipsec vendors care about privacy?

[Antonio Forzieri <antonio.forzieri@cefriel.it>]

Tero Kivinen wrote:
[SNIP]
>>(2) moving IDr, [CERT,] AUTH from msg 4 to msg 2.
>>    Namely, message 2 from R to I (in section 2.16) will look as:
>>                           <--  HDR, SAr1, KEr, Nr, IDr, [CERT,] AUTH
[SNIP]
> This will open the responders attack to polling attack. 
Agreed. I think we *MUST NOT* expose responder ID to polling attack... 
Or expose it as less as possible.

[SNIP]
> Some vendors refused to implement or use the aggressive mode of the
> IKEv1, just because of it required you to do expensive operations
> without ever knowing if there is anybody here. I would still guess,
> that most implementations would require the return routability check
> every time if this kind of protocol is used (at least I would in my
> implementation). 
Agreed.
I was thinking about something like this to "solve" the problem.

      	Alice                                  Bob
        -------                                -----

HDR,SAi,KEi,Ni,EAPC          -->

                              <--    HDR,SAr,KEr,Nr,[CERTREQ],HLC

HDR,SK{[CERTREQ],IDr,SAi2,   -->
        TSi,TSr,HLC}

                              <--    HDR,SK{IDr,[CERT],AUTH, EAP}

HDR,SK{IDi,EAP,[AUTH]}       -->

                              <--    HDR,SK{EAP,[AUTH],SAr2,TSi,TSr}

EAPC is a new payload (EAP Capability) and it contains a list of all 
authetication types supported by Alice: MD5,OTP,GTC,RSA... (for a 
complete list look here: http://www.networksorcery.com/enp/protocol/eap.htm)

This payload let Bob know that Alice is going to use legacy 
authentication in EAP. If Bob doesn't support any auth type in EAPC he 
will send a notification message NO-VALID-EAP-SUPPORTED.

In message 2 I've introduced HLC HIP Like Cookie, its primary scope is 
the same of return routability check plus a DoS protection. I think this 
is a better mechanism than return routability check as made in current 
ikev2 draft, in fact with HLC Alice *MUST solve* the quiz, while with 
the actual mechanism Alice can simply sniff the cookie and respond. Of 
course she has to be able of observe that traffic. The first scenario 
that comes in my mind is that of Alice being on a LAN and using spoofed 
IP address of the LAN she is on.
HLC mechanism is described in draft-ietf-moskowitz-hip-05.txt.

[COPY&PASTE BEGIN]
5.3.1. HIP Cookie Mechanism

    Responder    Generates 2 Random Numbers, I and J
                 Challenge = Ltrunc(SHA1(I|J),K)
                 Send I, K, and Challenge in HIP Cookie in R1
                 Saves I, K, and Challenge for Delta time

    Initiator    Do Until Challenge-response = Challenge
                 Challenge-response = Ltrunc(SHA1(I|Rand),K)
                 EndDo
                 Send I, Rand, and Challenge-response in HIP Cookie
                         in I2

    Responder    Match Response with Challenge based on I
                 Reject if Challenge-response = Challenge
                 Challenge-proof = Ltrunc(SHA1(I|Challenge-response),K)
                 Accept if Challenge-proof = Challenge
[COPY&PASTE END]

Alice MUST also specify a valid IDr, which can't be of type ID_IPV4_ADDR 
                         or ID_IPV6_ADDR, in the case such an ID is 
specified Bob will send Alice  an INVALID-RESPONTER-ID notification 
message. This mechanism ensure a grade of protection on IDr.("You 
Tarzan? Me wonder...")

IDi is in message 5, as Hugo proposed. However what seems to me harder 
to solve is that many EAP methods require a valid Identity before 
sending the first EAP message.
[SNIP]

>>It's all about tradeoffs and here I see privacy as the winner. Don't you?
Agreed.

What do the others think?

-- 
------------------------------------------------
Antonio Forzieri
CEFRIEL - Politecnico di Milano
Tesista Area E-Service Tecnologies
Tel: 02-23954.334 - email: forzieri@cefriel.it
ICQ# 177683894
------------------------------------------------