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

RE: A fix for main mode with preshared keys

     Do you mean that the responder computes hash(ID,Ni) for *every* entry 
     (ID, pre-shared key) in the database?!  That won't scale beyond a few 
     entries...
     
     Francisco


______________________________ Reply Separator _________________________________
Subject: RE: A fix for main mode with preshared keys
Author:  Non-HP-jyzhou (jyzhou@krdl.org.sg) at HP-ColSprings,mimegw5
Date:    12/7/99 6:56 PM


An additional payload HASH(1) = hash(IDii | Ni) could be sent in Step 3 
of Main Mode with pre-shared key to support remore access as well as 
identity protection. The responder can use HASH(1) to select pre-shared 
key.
     
Of course, this may affect the protocol performance since the responder 
need to re-compute HASH(1) from its (ID, pre-shared key) database to find 
the matched entry. But the performance bottleneck of a VPN is at IPsec 
rather than at IKE.
     
Jianying
     
     
On Tue, 7 Dec 1999, Andrew Krywaniuk wrote:
     
> >   For those of you who are concerned about massive evesdropping on the 
> > Internet and tracking of opaque blobs ("dfnmtynioghora was in Grozny
> > on Tuesday and Khartoum on Thursday, it _must_ Osama Bin 
> > Laden! Next time
> > you see that ID_KEY_ID go get him.") the value can change with each 
> > authentication by hashing with some exchange specific 
> > information like 
> > the nonces:
> > 
> >      ID_KEY_ID[x+1] = hash(ID_KEY_ID[x] | Ni | Nr) 
> >      where ID_KEY_ID[0] = the initial seeded value 
> > 
> > Once you sucessfully authenticate using ID_KEY_ID[x] update 
> > the pre-shared
> > key database so the existing pre-shared key (and hidden 
> > "real" identity)
> > will not be associated with ID_KEY_ID[x+1]. 
> 
> So what you are suggesting is essentially a second pre-shared key (the iv
> for the ID_KEY_ID). And this must always be synchronized between the peers, 
> so if one peer crashes and has to restore his HD from backups or if the
> negotiation is aborted between the transmission and reception of packets N 
> and N+1 (for some N), then they must manually resynchronize.
> 
> I thought IKE was a stateless protocol. :-) 
> 
> Is it really that hard to not make SKEYID_e dependent on the shared secret? 
> It can still be used to derive SKEYID_d. I know you said you were concerned 
> about changing the keymat generation technique for an established protocol, 
> but isn't it the general derivation technique that requires analysis and not 
> the specific definition of SKEYID_e as prf(SKEYID, SKEYID_a | g^xy | CKY-I | 
> CKY-R | 2).
> 
> Andrew
> _______________________________________________ 
>  Beauty without truth is insubstantial.
>  Truth without beauty is unbearable. 
>
References: