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 <[email protected]> wrote: > Hi, > > to, 2020-02-20 kello 08:58 -0800, Eric Rescorla kirjoitti: > > > > > > On Thu, Feb 20, 2020 at 7:38 AM Miika Komu <[email protected]> > > 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 < > > > [email protected]> > > > > 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. >
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
