Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

Typically in security protocols we look for demonstrations of this. What is
your argument for why it cannot?

-Ekr


On Fri, Feb 21, 2020 at 4:25 AM Miika Komu <[e-mail]> wrote:

> Hi,
>
> to, 2020-02-20 kello 08:58 -0800, Eric Rescorla kirjoitti:
> >
> >
> > On Thu, Feb 20, 2020 at 7:38 AM Miika Komu <[e-mail]>
> > wrote:
> > > Hi Eric,
> > >
> > > to, 2020-02-20 kello 06:04 -0800, Eric Rescorla kirjoitti:
> > > >
> > > >
> > > > On Wed, Feb 19, 2020 at 10:50 PM Miika Komu <
> > > [e-mail]>
> > > > wrote:
> > > > > Hi Eric,
> > > > >
> > > > > ke, 2020-02-19 kello 13:20 -0800, Eric Rescorla kirjoitti:
> > > > > > > > > > S 5.8.
> > > > > > > > > >>
> > > > > > > > > >>    5.8.  RELAY_HMAC Parameter
> > > > > > > > > >>
> > > > > > > > > >>       As specified in Legacy ICE-HIP [RFC5770], the
> > > > > > > RELAY_HMAC
> > > > > > > > > parameter
> > > > > > > > > >>       value has the TLV type 65520.  It has the same
> > > > > > > semantics
> > > > > > > > > as RVS_HMAC
> > > > > > > > > >>       [RFC8004].
> > > > > > > > > >
> > > > > > > > > > What key is used for the HMAC?
> > > > > > > > >
> > > > > > > > > clarified this as follows:
> > > > > > > > >
> > > > > > > > > [..] It has the same semantics as RVS_HMAC as specified
> > > in
> > > > > > > section
> > > > > > > > > 4.2.1
> > > > > > > > > in [RFC8004].  Similarly as with RVS_HMAC, also
> > > RELAY_HMAC
> > > > > is
> > > > > > > is
> > > > > > > > > keyed
> > > > > > > > > with the HIP integrity key (HIP-lg or HIP-gl as
> > > specified
> > > > > in
> > > > > > > > > section 6.5
> > > > > > > > > in [RFC7401]), established during the relay
> > > registration
> > > > > > > procedure
> > > > > > > > > as
> > > > > > > > > described in Section 4.1.
> > > > > > > >
> > > > > > > > This seems like it might have potential for cross-
> > > protocol
> > > > > > > attacks on
> > > > > > > > the key. Why
> > > > > > > > is this OK>
> > > > > > >
> > > > > > > this is standard way of deriving keys in HIP. The keying
> > > > > procedure
> > > > > > > is
> > > > > > > the same as with specified in RFC8004. If there is some
> > > attack
> > > > > > > scenario, please describe it in detail?
> > > > > > > Or is there some editorial issue here?
> > > > > >
> > > > > > I'm not sure. When I read this text it appears to say that
> > > you
> > > > > should
> > > > > > be using the same key for two kinds of messages. Is that
> > > correct?
> > > > >
> > > > > the key is always specific to a Host Association, i.e., unique
> > > > > between
> > > > > a Relay Client and a Relay Server. So if there is a Rendezvous
> > > > > server
> > > > > (used with RVS_HMAC), this would be a different host and
> > > different
> > > > > Host
> > > > > Association. If the same host provides both rendezvous and
> > > relay
> > > > > service, it should be fine to reuse the same key.
> > > >
> > > > Why is that OK? Generally we try not to do this. Do you have a
> > > proof
> > > > that it is not possible to have one message mistaken for another?
> > >
> > > so I assume we are talking about the (artificial) case where a
> > > single
> > > host provides both Relay and Rendezvous service, and is
> > > communicating
> > > with a single registered Client? It's the same control channel, so
> > > I
> > > don't see any need to have different HMAC keys for different
> > > messages
> > > since it's still the same two hosts. Or maybe I misunderstood your
> > > scenario, so please elaborate?
> >
> > The concern is what's known as a "cross-protocol" attack. Is there
> > any situation in which there might be ambiguity about two message
> > types that are protected with the same key?
>
> I don't see any case where this could occur.
>