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

From: Miika Komu <[email-masked]>
Date: Wed, 19 Feb 2020 21:08:26 +0000

Hi Eric,

thanks for your comments, my response below.

ke, 2018-12-26 kello 17:04 -0800, Eric Rescorla kirjoitti:
> 
> 
> On Wed, Nov 7, 2018 at 1:37 PM Miika Komu <[email-masked]>
> wrote:
> > Hi Eric,
> > 
> > apologies for the belated response, I am not working on HIP
> > anymore, so 
> > it has been rather difficult to find time for this.
> > 
> > On 5/4/18 22:34, Eric Rescorla wrote:
> > > Eric Rescorla has entered the following ballot position for
> > > draft-ietf-hip-native-nat-traversal-28: Discuss
> > > 
> > > When responding, please keep the subject line intact and reply to
> > all
> > > email addresses included in the To and CC lines. (Feel free to
> > cut this
> > > introductory paragraph, however.)
> > > 
> > > 
> > > Please refer to 
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > > 
> > > 
> > > The document, along with other ballot positions, can be found
> > here:
> > > 
> > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/
> > > 
> > > 
> > > 
> > > ---------------------------------------------------------------
> > -------
> > > DISCUSS:
> > > ---------------------------------------------------------------
> > -------
> > > 
> > > Rich version of this review at:
> > > https://mozphab-ietf.devsvcdev.mozaws.net/D3099
> > > 
> > > 
> > > I am very familiar with ICE and yet I found this document
> > extremely
> > > hard to follow. The problem is that it cherry-picks pieces of ICE
> > and
> > > I'm just not sure that it's a complete specification when put all
> > > together. I have noted a number of places where I actually am not
> > sure
> > > how to implement something, and fixing those will resolve this
> > > DISCUSS, but IMO you really should totally rewrite this document
> > > either (a) as a variant of ICE or (b) as an entirely new document
> > not
> > > with a pile of new text and then references out to ICE sections.
> > 
> > the expected receivers of the work are the implementers of RFC5770,
> > so 
> > the draft follows the sectioning of the RFC5770 (which has two 
> > interoperable implementations).
> > 
> > If I understood your comment right, the variant of ICE (a) would
> > follow 
> > the ICE document structure but then the document would not serve
> > anymore 
> > HIP implementers so well. What comes to option (b), I think it
> > would 
> > make the the document quite long if we replicated everything in the
> > ICE 
> > specification (and possibly from the HIP specifications) in the
> > draft.
> 
> Yes, it would be long, because ICE is complicated. It would also be
> complete.
> As I said in my initial ballot, if you resolve the ambiguities I
> noted I will
> clear my DISCUSS, but I think that this document should really be
> rewritten
> and i would urge the AD to require it.
> 
> 
>  
> > > S 4.6.2.
> > >>    
> > >>       A host may receive a connectivity check before it has
> > received the
> > >>       candidates from its peer.  In such a case, the host MUST
> > immediately
> > >>       generate a response, and then continue waiting for the
> > candidates.  A
> > >>       host MUST NOT select a candidate pair until it has
> > verified the pair
> > >>       using a connectivity check as defined in Section 4.6.1.
> > > 
> > > Are you supposed to put this on a TODO check list as with ICE?
> > 
> > I believe you refer to the triggered-check queue:
> > 
> > https://tools.ietf.org/html/rfc8445#section-6.1.4.1
> > 
> > I changed the text as follows:
> > 
> > A host may receive a connectivity check before it has
> > 
> > received the candidates from its peer. In such a case, the
> > 
> > host MUST immediately generate a response by placing it in the 
> > triggered-check queue, and then continue
> > waiting for the candidates.
> 
> Well, this isn't generating a response, it's queueing a response.

reworded as follows:

In such a case, the host MUST immediately queue a response by placing
it in the triggered-check queue, and  then continue waiting for the
candidates.

> > > 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?

> > > S 4.2.
> > >>       deployments in order to enable it by software
> > configuration update if
> > >>       needed at some point.  A host SHOULD employ only a single
> > server for
> > >>       gathering the candidates for a single HIP association;
> > either one
> > >>       server providing both Control and Data Relay Server
> > functionality, or
> > >>       one Control Relay Server and also Data Relay Server if the
> > >>       functionality is offered by another server.  When the
> > relay service
> > > 
> > > How does this interact with mult-layered NAT?>
> > 
> > No different from ICE with separated STUN and TURN servers multi-
> > layer 
> > NAT scenarios. Should we mention something about the issues related
> > to 
> > some specific scenario?
> 
> Well, with multi-layered NAT, you actually want a STUN server at each
> level
> so that you minimize hairpinning. But you recommend against that
> here.

good point. This unnecessary constraint has been removed as it was also
requested by Benjamin Kaduk.

> > > S 5.7.
> > >>       | Reserved  | 0        | Reserved for future extensions   
> >          |
> > >>       | Preferred | 0 or 1   | Set to 1 for a Locator in R1 if
> > the        |
> > >>       | (P) bit   |          | Responder can use it for the rest
> > of the   |
> > >>       |           |          | base exchange, otherwise set to
> > zero       |
> > >>       | Locator   | Variable | Locator lifetime in seconds     
> >           |
> > >>       | Lifetime  |          |                                 
> >           |
> > > 
> > > What is the purpose of this? It's not an ICE parameter.
> > 
> > In HIP, locators have a maximum lifetime after which they become 
> > deprecated (RFC8046). Should add something here?
> Yes

Added a reference:

"Locator lifetime in seconds, see Section 4 in [RFC8046]"

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 19 Feb 2020 13:20:59 -0800

I am no longer an area director, so generally I  suggest you take up these
comments with the current ADs.

> 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?

-Ekr

---

From: Miika Komu <[email-masked]>
Date: Thu, 20 Feb 2020 06:50:45 +0000

Hi Eric,

ke, 2020-02-19 kello 13:20 -0800, Eric Rescorla kirjoitti:
> 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.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 20 Feb 2020 12:44:55 +0000

Thanks for the quick response, Eric R!

Eric V, could you please let Miika know how do you want to proceed?

For background, this is the status of the ballot for this draft:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ballot/

Thanks,

Gonzalo

From: Eric Rescorla <[email-masked]>
Sent: Wednesday, February 19, 2020 23:21
To: Miika Komu <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Gonzalo Camarillo <[email-masked]>; [email-masked]
Subject: Re: Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

I am no longer an area director, so generally I  suggest you take up these comments with the current ADs.

On Wed, Feb 19, 2020 at 1:08 PM Miika Komu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

ke, 2018-12-26 kello 17:04 -0800, Eric Rescorla kirjoitti:
>
>
> On Wed, Nov 7, 2018 at 1:37 PM Miika Komu <[email-masked]<mailto:[email-masked]>>
> wrote:
> > Hi Eric,
> >
> > https://www.ietf.org/iesg/statement/discuss-criteria.html<https://protect2.fireeye.com/v1/url?k=4df5b2b9-117c6895-4df5f222-0cc47ad93da2-c63b54a62d6e5f37&q=1&e=7142dcd0-5df7-4a81-aaf2-5f5e8ee90c29&u=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html>
> > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/<https://protect2.fireeye.com/v1/url?k=d572ef6f-89fb3543-d572aff4-0cc47ad93da2-ec72a0e72bb1caa3&q=1&e=7142dcd0-5df7-4a81-aaf2-5f5e8ee90c29&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-hip-native-nat-traversal%2F>
> > >
> > >
> > >
> > > https://mozphab-ietf.devsvcdev.mozaws.net/D3099<https://protect2.fireeye.com/v1/url?k=770d951d-2b844f31-770dd586-0cc47ad93da2-ca3aaf2e40abb1bd&q=1&e=7142dcd0-5df7-4a81-aaf2-5f5e8ee90c29&u=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD3099>
> > >
> > >
> > https://tools.ietf.org/html/rfc8445#section-6.1.4.1<https://protect2.fireeye.com/v1/url?k=b1768830-edff521c-b176c8ab-0cc47ad93da2-0e377742be9101ab&q=1&e=7142dcd0-5df7-4a81-aaf2-5f5e8ee90c29&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8445%23section-6.1.4.1>
> >

reworded as follows:

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?

-Ekr

Added a reference:

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Feb 2020 06:04:49 -0800

> 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?

-Ekr

---

From: Miika Komu <[email-masked]>
Date: Thu, 20 Feb 2020 15:38:24 +0000

Hi Eric,

to, 2020-02-20 kello 06:04 -0800, Eric Rescorla kirjoitti:
> > > > > > in [RFC8004].  Similarly as with RVS_HMAC, also RELAY_HMAC
> > is
> > > > is
> > > > > > keyed 
> > > > this is standard way of deriving keys in HIP. The keying
> > procedure
> > > > is
> 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?

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Feb 2020 08:58:22 -0800

> 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?

-Ekr

---

From: Miika Komu <[email-masked]>
Date: Fri, 21 Feb 2020 12:25:41 +0000

Hi,

to, 2020-02-20 kello 08:58 -0800, Eric Rescorla kirjoitti:
> > > On Wed, Feb 19, 2020 at 10:50 PM Miika Komu <
> > [email-masked]>
> > > wrote:
> > > > Hi Eric,
> > > > 
> > > > > > > > [..] It has the same semantics as RVS_HMAC as specified
> > in
> > > > > > section
> > > > > > > > 4.2.1 
> > > > > > > > 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 
> > > > > > > This seems like it might have potential for cross-
> > protocol
> > > > > > attacks on
> > > > > > > the key. Why
> > > > > > > is this OK>
> > > > > > 
> > > > > I'm not sure. When I read this text it appears to say that
> > you
> > > > should
> > > > (used with RVS_HMAC), this would be a different host and
> > different
> > > > Host
> 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.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Feb 2020 05:34:47 -0800

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

-Ekr

---

From: Miika Komu <[email-masked]>
Date: Fri, 21 Feb 2020 14:36:57 +0000

Hi Eric,

so your original question was:

"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?"

No ambiguity about the message types, because the messages between
relay client and relay server carry always either a RELAY_FROM or
RELAY_TO parameter (depending on direction) and this is covered by the
HMAC.

In the rendezvous case, you have different FROM and VIA_RVS parameters,
also covered by HMACs.

pe, 2020-02-21 kello 05:34 -0800, Eric Rescorla kirjoitti:
> Typically in security protocols we look for demonstrations of this.
> What is your argument for why it cannot?
> 
> -Ekr
> 
> 
> > > On Thu, Feb 20, 2020 at 7:38 AM Miika Komu <
> > [email-masked]>
> > > wrote:
> > > > Hi Eric,
> > > > 
> > > > > > > > > > >>       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].
> > > > > > > > > > > 
> > > > > > 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
> > > > > Why is that OK? Generally we try not to do this. Do you have
> > a
> > > > proof
> > > > with a single registered Client? It's the same control channel,
> > so
> > > > I

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Feb 2020 06:53:10 -0800

I do not have time to assess this claim. I would encourage the security ADs
to do so.