[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: A fix for main mode with preshared keys
> 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.
Follow-Ups: