Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
I do not have time to assess this claim. I would encourage the security ADs to do so. On Fri, Feb 21, 2020 at 6:36 AM Miika Komu wrote: > 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 Fri, Feb 21, 2020 at 4:25 AM Miika Komu > > wrote: > > > Hi, > > > > > > to, 2020-02-20 kello 08:58 -0800, Eric Rescorla kirjoitti: > > > > > > > > > > > > On Thu, Feb 20, 2020 at 7:38 AM Miika Komu < > > > miika.k...@ericsson.com> > > > > 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 < > > > > > miika.k...@ericsson.com> > > > > > > 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
Re: [Hipsec] Re-doing the IESG ballot for draft-ietf-hip-native-nat-traversal
On Fri, Feb 21, 2020 at 6:21 AM Miika Komu wrote: > Hi Eric, > > I disagree about the overhead occuring only during set up time because > STUN message format is incompatible with ESP formatting, so an > implementation needs to constantly monitor and intercept STUN packets > from the data-plane traffic. This causes a continuous overhead to the > data plane, so it is not only about set up time. Please check the draft > or hipsec mailing for more detailed discussion on this. > Assuming you're talking about Appendix B, this is just a bare assertion that is no more convincing than the one you make here. I would make several points here: 1. STUN packets are trivial to detect and that detection is *far* cheaper than doing any kind of cryptographic processing. Moreover, you only need to invoke it once you have determined that you don't have an ESP packet on your hands, which you have to do *anyway*, because you need to demux ESP packets from HIP setup packets. Failing that, you could just do STUN demuxing for packets which are unprocessable as ESP (which you would need to have some code for anyway). 2. Once the ICE handshake has completed, the only reason to send STUN packets is for keepalives, which ICE explicitly permits to be able to sent by non-STUN mechanisms, so you could simply profile ICE to use a non-STUN keepalive. Beyond that, you can simply ignore STUN as long as there aren't any connections being set up. To the extent to which your argument relies one endpoint performance, I really think that some measurements and a demonstration that you attempted to optimize the code in the obvious ways are in order. More generally, this sort of non-specific performance argument is often adduced in favor of designing something new, but ICE is a very complicated piece of machinery that has taken the IETF quite a lot of time to build and refine. This protocol is subtly different in ways that don't seem entirely obvious and so I think we should be quite cautious about issuing it as a Proposed Standard when we have a pre-existing protocol at hand, given that the arguments for doing so seem to rest on a rather thin set of arguments about performance. -Ekr > pe, 2020-02-21 kello 05:38 -0800, Eric Rescorla kirjoitti: > > I would like to note for the record that I do not find the arguments > > in the applicability statement at all persuasive. They are > > principally about performance but ICE occurs at setup time (so CPU > > performance is not much of an issue) and is inherently so, with > > pacing and RTT the dominant factors (and so the system architecture > > issues are unpersuasive). As I am no longer an AD, this is just > > opinion, but were I the AD, I would insist on a strong rationale. > > > > -Ekr > > > > > > On Fri, Feb 21, 2020 at 4:35 AM Eric Vyncke (evyncke) < > > evyn...@cisco.com> wrote: > > > Hi, > > > > > > The first IESG ballot for the draft-ietf-hip-native-nat-traversal > > > was done in May 2018 and was blocked by a couple of DISCUSS by the > > > 2018 IESG. The main issue IMHO was around “why not reusing plain > > > ICE?”; the authors in discussion with Adam Roach have provided an > > > applicability statement and a justification on why “plain ICE” does > > > not work efficiently when combined with HIP + additional text or > > > replies for the remaining DISCUSS & COMMENT. > > > > > > The diff are > > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-30=draft-ietf-hip-native-nat-traversal-28 > > > > > > I have reviewed all COMMENT and DISCUSS from 2 years ago and it > > > appears to me that they are all addressed (including those from > > > 2018 AD who are no more AD in 2020 – they are in cc). The changes > > > in the document are minor and I am confident that neither a WG Last > > > Call not an IETF Last Call is required. I am therefore placing the > > > document in the next IESG telechat and opening a new IESG ballot. > > > > > > Thank you for the authors on their energy to keep the document > > > useful, > > > > > > Regards, > > > > > > -éric > > > > > > > ___ > > Hipsec mailing list > > Hipsec@ietf.org > > https://www.ietf.org/mailman/listinfo/hipsec > ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
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 Fri, Feb 21, 2020 at 4:25 AM Miika Komu > wrote: > > Hi, > > > > to, 2020-02-20 kello 08:58 -0800, Eric Rescorla kirjoitti: > > > > > > > > > On Thu, Feb 20, 2020 at 7:38 AM Miika Komu < > > miika.k...@ericsson.com> > > > 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 < > > > > miika.k...@ericsson.com> > > > > > 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 Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Re-doing the IESG ballot for draft-ietf-hip-native-nat-traversal
Hi Eric, I disagree about the overhead occuring only during set up time because STUN message format is incompatible with ESP formatting, so an implementation needs to constantly monitor and intercept STUN packets from the data-plane traffic. This causes a continuous overhead to the data plane, so it is not only about set up time. Please check the draft or hipsec mailing for more detailed discussion on this. pe, 2020-02-21 kello 05:38 -0800, Eric Rescorla kirjoitti: > I would like to note for the record that I do not find the arguments > in the applicability statement at all persuasive. They are > principally about performance but ICE occurs at setup time (so CPU > performance is not much of an issue) and is inherently so, with > pacing and RTT the dominant factors (and so the system architecture > issues are unpersuasive). As I am no longer an AD, this is just > opinion, but were I the AD, I would insist on a strong rationale. > > -Ekr > > > On Fri, Feb 21, 2020 at 4:35 AM Eric Vyncke (evyncke) < > evyn...@cisco.com> wrote: > > Hi, > > > > The first IESG ballot for the draft-ietf-hip-native-nat-traversal > > was done in May 2018 and was blocked by a couple of DISCUSS by the > > 2018 IESG. The main issue IMHO was around “why not reusing plain > > ICE?”; the authors in discussion with Adam Roach have provided an > > applicability statement and a justification on why “plain ICE” does > > not work efficiently when combined with HIP + additional text or > > replies for the remaining DISCUSS & COMMENT. > > > > The diff are > > https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-30=draft-ietf-hip-native-nat-traversal-28 > > > > I have reviewed all COMMENT and DISCUSS from 2 years ago and it > > appears to me that they are all addressed (including those from > > 2018 AD who are no more AD in 2020 – they are in cc). The changes > > in the document are minor and I am confident that neither a WG Last > > Call not an IETF Last Call is required. I am therefore placing the > > document in the next IESG telechat and opening a new IESG ballot. > > > > Thank you for the authors on their energy to keep the document > > useful, > > > > Regards, > > > > -éric > > > > ___ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
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 wrote: > Hi, > > to, 2020-02-20 kello 08:58 -0800, Eric Rescorla kirjoitti: > > > > > > On Thu, Feb 20, 2020 at 7:38 AM Miika Komu > > 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 < > > > miika.k...@ericsson.com> > > > > 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 Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
[Hipsec] Éric Vyncke's Yes on draft-ietf-hip-native-nat-traversal-30: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-hip-native-nat-traversal-30: Yes 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/ -- COMMENT: -- The -30 version addresses all DISCUSSs and COMMENTs raised during the May 2018 first ballot on version -28. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
[Hipsec] Re-doing the IESG ballot for draft-ietf-hip-native-nat-traversal
Hi, The first IESG ballot for the draft-ietf-hip-native-nat-traversal was done in May 2018 and was blocked by a couple of DISCUSS by the 2018 IESG. The main issue IMHO was around “why not reusing plain ICE?”; the authors in discussion with Adam Roach have provided an applicability statement and a justification on why “plain ICE” does not work efficiently when combined with HIP + additional text or replies for the remaining DISCUSS & COMMENT. The diff are https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-30=draft-ietf-hip-native-nat-traversal-28 I have reviewed all COMMENT and DISCUSS from 2 years ago and it appears to me that they are all addressed (including those from 2018 AD who are no more AD in 2020 – they are in cc). The changes in the document are minor and I am confident that neither a WG Last Call not an IETF Last Call is required. I am therefore placing the document in the next IESG telechat and opening a new IESG ballot. Thank you for the authors on their energy to keep the document useful, Regards, -éric ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
Hi, to, 2020-02-20 kello 08:58 -0800, Eric Rescorla kirjoitti: > > > On Thu, Feb 20, 2020 at 7:38 AM Miika Komu > 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 < > > miika.k...@ericsson.com> > > > 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 Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Ben Campbell's Abstain on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)
Thank you Ben, As a side note, I have observed that the authors have addressed all your review comments in the -29 version. The current plan is to do a new ballot as the IESG has changed since the last one. -éric From: iesg on behalf of Ben Campbell Date: Friday, 21 February 2020 at 00:19 To: Miika Komu Cc: "hipsec@ietf.org" , "hip-cha...@ietf.org" , "i...@ietf.org" , Gonzalo Camarillo , "draft-ietf-hip-native-nat-traver...@ietf.org" Subject: Re: Ben Campbell's Abstain on draft-ietf-hip-native-nat-traversal-28: (with COMMENT) Hi, I am no longer an area director. I leave it to the current area directors to decide how to proceed with the updated version. Thanks, Ben. On Feb 19, 2020, at 2:43 PM, Miika Komu mailto:miika.k...@ericsson.com>> wrote: Hi Ben, thanks for your comments! My response below. ke, 2018-05-09 kello 19:05 -0700, Ben Campbell kirjoitti: Ben Campbell has entered the following ballot position for draft-ietf-hip-native-nat-traversal-28: Abstain 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/ --- --- COMMENT: --- --- I support all points of Ekr's discuss and comment points. I think this either needs to use ICE mostly as is (maybe with some minor profiling) or it needs to be self-contained here. I understand the material in appendix B, but the current mix seems untenable for implementors. Therefore I am balloting "abstain". I will reconsider that position if there is a substantial reorganization. the current document has been organized for implementors of RFC5770 in mind. Substantive Comments: I share Alissa's question about why this is standard track when the previous work has been experimental. HIP WG decided to move all of its experimental work to standards track. §1, second paragraph: The citation for the version of ICE used by "legacy ICE-HIP" should be RFC5245, not the bis version. thanks, corrected. §2: There are a number of lower-case keywords. Please use the RFC 8174 boilerplate. boilerplate added. Please comment some specific lower-case keyword is incorrect in your opinion. §4.2: - paragraph 5: Is everything in this paragraph from the ICE specification? I suspect not, but it's hard to tease out what is from ICE and what is new specification. It would be helpful to reference the ICE bits by section number. it is either adapted from ICE (by e.g. changing "agent" to "host" or referencing the ICE spec (by sections). Based on the earlier reviews, the text has evolved now into the following: The rules in section 5.1.1 in [RFC8445] for candidate gathering are followed here. A number of host candidates (loopback, anycast and others) should be excluded as described in section 5.1.1.1 of the ICE specification [RFC8445]. Relayed candidates SHOULD be gathered in order to guarantee successful NAT traversal, and implementations SHOULD support this functionality even if it will not be used in deployments in order to enable it by software configuration update if needed at some point. Similarly as explained in section 5.1.1.2 of the ICE specification [RFC8445], if an IPv6- only host is in a network that utilizes NAT64 [RFC6146] and DNS64 [RFC6147] technologies, it may also gather IPv4 server- reflexive and/or relayed candidates from IPv4-only Control or Data Relay Servers. IPv6-only hosts SHOULD also utilize IPv6 prefix discovery [RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and generate server-reflexive candidates for each IPv6-only interface, accordingly. The NAT64 server-reflexive candidates are prioritized like IPv4 server-reflexive candidates. - paragraph 6: I'm confused in that I thought the previous text said that native ICE-HIP does not use STUN. you mean paragraph 7? Gathering of candidates MAY also be performed by other means than described in this section. For example, the candidates could be gathered as specified in Section 4.2 of [RFC5770] if STUN servers are available, or if the host has just a single interface and no STUN or Data Relay Server are available. Nothing prevents an implementation from gathering candidates via STUN but the recommended way is HIP control Relay as the "MAY" indicates here. §6: I am skeptical of the assertion that the security considerations for Native ICE-HIP are no different than those for Legacy ICE-HIP. I have changed this now to a more precise statement: Since the control plane protocol and Control Relay Server
