Re: Do ipsec vendors care about privacy?

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

[SNIP]
I think that vendors *care* about privacy... Or at least they should. :-).

The solutions you proposed solves the problem of protecting the 
iniziator ID from attive attck, however they let the responder ID opend 
to passive attack.

> (1) Simply defer the sending of the user's identity IDi from message 
> 3 to message 5 (that is, after message 4 in which the responder authenticates
> itself).  The difficuty here is that the responder does not have IDi to base
> its choice of EAP method in message 4. I do not know how much of a practical 
> problem this is (it was never pointed as such in the case of PIC in the ipsra
> wg), but others will know better.
I think that this is the simplest solution of the two. Initiator, when 
it is going to use "legacy autentication", does not have to send IDi to 
the responder. This is not a difficulty for the responder (I think). 
When Bob doesn't receive IDi and AUTH payload in message 3 will 
understand that Alice is going to use a legacy authentication method, 
and he send an EAP(Request, Identity) in message 4. Alice can send her 
IDi in EAP(Response, Identity) in message 5. This change in IKEv2 will 
make handshake 1RTT longer, however I think this isn't a great problem 
when we are interactin with a human.


      Initiator(Alice)                   Responder(Bob)
       -----------                        -----------
        HDR, SAi1, KEi, Ni         -->

                                   <--    HDR, SAr1, KEr, Nr, [CERTREQ]

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

                                   <--    HDR, SK {IDr, [CERT,] AUTH,
                                                 EAP(Request, Identity)}
        HDR, SK {EAP(Reply, IDi)}  -->

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

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

Of course this proposal let IDr opened to polling attack. But which 
identity we have to protect? In a message from Radia Perlman:

"...However, when writing IKEv2, we decided that there was
more of a problem with a "polling attack", where someone
could find out who was listening at a particular IP address just
by initiating a connection to it. The WG, when faced with
the two styles, seemed to have consensus around avoiding the
polling attack. The reasoning was that IKE is a peer-to-peer protocol 
where either side can initiate, and the polling attack is way easier 
(just initiate a connection to an IP address) than impersonating the
responder's IP address and seeing who connects..."

So again: "How important is identity protection? and which ID we *MUST* 
protect?"

> (2) Let the responder authenticate itself already  in message 2.  This can 
> be achieved by moving the AUTH and IDr payloads from message 4 to message 2. 
> If we do not require encrypting these fields then the change is simple. 
> Adding encryption is possible but requires applying SK{} from the middle of
> message 2 which is more complex. I suggest doing it simple, i.e. without
> encryptioni (also integrity protection is not needed here). This leaves 
> the identity of R in the plain but this is ONLY for
> the legacy authentication scenario in which protecting the responder
> (server/gateway) identity is of little (or no) importance.
This solution allow us to save the extra RTT, however it implies that 
Bob knows when the Alice is going to use EAP. (Your proposal is to 
change IKev2 *only* when using "legacy authentication", right?)

[SNIP]
> Hugo
  Am I missing something?

[SNIP]

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