[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should Alice say who she wants to talk to?
Actually, this is precisely what the "suggested ID" draft Bill Sommerfeld
and I have, which Bill discussed briefly on the Wednesday session. The name
is draft-keromytis-ike-id-00.txt.
This was for IKEv1, and mostly intended for bidirectional user-keying, but it
can be used for what you want it. For any of the SoI proposals, the same
extension can be made --- and, as you point out, it makes the Responder's
identity public (in IKEv1 it does not, because of the 6 messages in Phase 1).
-Angelos
In message <200112170205.VAA02738@bcn.East.Sun.COM>, Radia Perlman - Boston Cen
ter for Networking writes:
>I was wondering about how IPsec might support having a bunch
>of services hosted at the same IP address, or even hosted
>behind a firewall, but all accessible through the firewall's IP address.
>SSL/TLS doesn't do this either, but it seems like it might be
>a useful thing.
>
>The idea is that there would be a whole bunch of services, all reachable
>to the world through a single IP address. IKE would have some
>port (500 say). It can connect Alice to a bunch of services, say
>foo and bar. When Alice connects to port 500 she says (probably
>in message 1 of the handshake), "I'd
>like to talk to service foo", and the IKE process (which must have
>certificates and keys for each of the services) uses that to know
>what certificate and key to use, i.e., which "Bob" persona to take on.
>
>And if people are worried about plausible deniability, Alice need not
>sign Bob's name (IKEv2 says "sign everything in messages 1 and 2, but
>that's because Bob's name isn't there right now...if it were, then Alice could
>sign everything except Bob's name, and add Bob's name into the
>integrity check in message 3).
>
>This would be an optional field in message 1, and obviously won't
>hide Bob's identity.
>
>Note that HTTP 1.1 has this feature of allowing Alice to say who she
>wants to talk to.
>
>Radia
References: