[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should Alice say who she wants to talk to?
On Mon, 17 Dec 2001, Sara Bitan wrote:
> Radia - why aren't the (IKEv2 analog to) phase II IDs sufficient to handle
> that scenario you are describing?
Because they are way too late in the exchange to be of any use in picking
which identity a server may want to pose as.
> Does each one of the services/ the hosts behind the firewall have a distinct
> private/public key pair?
>
Yes.
> And another comment: if you move IDr to message number 1, and the initiator
> doesn't sign it since you want to avoid introducing NR, then the protocol is
> exposed to the DVW attack. As you said, the simple algorithm that IKEv2 uses
> "sign messages 1 and 2, and integrity protect messages 3 and 4" doesn't work
> any more, hence you must add the responder's identity explicitly to the MAC
> calculation in message 3.
> I think that the option that you are proposing to add to IKEv2 is a good
> motivation to adopt SIGMA's way of explicitly MACing the identities.
> If the protocol specifies all the components that ensure the correctness of
> the key exchange cryptographic protocol (i.e. the MAC'd identities and
> signed public exponent and nonces) explicitly, then you have the advantage
> of moving IDs and exponents (almost) freely between messages without the
> risk of breaking the protocol.
> If we will not include the identities explicitly under the MAC we will have
> to always twick the protocol to keep it secure, and ask the cryptographers
> to prove that the twicks are indeed not breaking the protocol.
>
Nit: s/twicks/tweaks/g
jan
> Sara.
> ----- Original Message -----
> From: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
> To: <ipsec@lists.tislabs.com>
> Sent: Monday, December 17, 2001 4:05 AM
> Subject: Should Alice say who she wants to talk to?
>
>
> > 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
> >
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
Follow-Ups:
References: