[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Decrypting ID payload in Main Mode w/shared secrets
> You must have some out-of-band mechanism to distribute this pre-shared
> key (the real one, not the "open secret") on the scale you desire so
> why not just distribute public keys bound to identities through that
> channel and then use the pubic key encryption mode?
Shared secrets already work -- we could add this in a day (and we have
users who want it yesterday). The PK stuff starts to tie into certs,
patents, DNS, and all the rest of the complications, which will take
longer to sort out.
> What you propose would require another exchange anyway since
> everyone else's implementation doesn't create one set of SKEYID(a_e_d)
> state and then throw it away and make more.
I propose implementing something that the IETF specs explicitly don't
permit -- an extension -- so of course we'd only interoperate with
others who also implement the extension. If it got popular, of
course, IETF could adopt it. From my recent scan of the IPSEC mailing
list archives, it seems like a lot of implementers stumbled over this
and were looking for a solution.
I don't see why it would take another exchange (of packets).
> Using a well-known pre-shared key would mean that anybody who knows
> it could derive the key used to encrypt the identities (which is now based
> completely on known information: "open secret" and the 2 nonces which are
> passed in the clear) and that sort of defeats your purpose.
I think you're confusing SKEYID and SKEYID_e.
RFC2049: SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
The just-computed D-H shared secret (g^xy) is in the encryption key.
The identities ARE protected against passive attacks. A man in the
middle could impersonate the other side, thereby knowing g^xy, and get
the claimed identity of one or both sides. But they would be detected
one packet later -- when they couldn't decrypt Quick Mode packets
because they didn't know the shared secret matching the identities.
> And why "open secret" when we have draft-ietf-ipsec-internet-key-00.txt?
You're right, I stand corrected. Is that a standards-track document? :-)
What's the derivation of the shared secret it proposes,
"mekmitasdigoat". As you can tell, it wasn't as mnemonic for me as
"open secret", since I'd forgotten all about that draft.
John
Follow-Ups:
References: