Hi Benjamin,
ti, 2020-03-03 kello 20:09 -0800, Benjamin Kaduk via Datatracker
kirjoitti:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-30: 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:
> ---
> ---
>
> One fairly minor point to start: Section 4.3 says that we define a
> new
> mode (ICE-HIP-UDP) for the NAT_TRAVERSAL_MODE parameter type, but
> then
> goes on to say that "the presence of the parameter in a HIP base
> exchange means that the end-host supports NAT traversal extensions
> defined in this document". If I undrestand correctly, only the
> specific
> presence of the ICE-HIP-UDP mode of the NAT_TRAVERSAL_MODE parameter
> does so, and so to say that the presence of "the [NAT_TRAVERSAL_MODE]
> parameter" indicates support for this document would be backwards
> incompatible with RFC 5770.
>
> I'd also like to delve a little further into the potential
> "cross-protocol" attack (same protocol, really, but the same attack)
> that Ekr raised, between RVS_HMAC and RELAY_HMAC. This is probably a
> "discuss discuss", so let's see where it leads...
>
> The semantics for either type of HMAC is that it is an HMAC over the
> HIP
> packet excluding itself and subsequent parameters. Pulling up the
> HIP
> packet format from RFC 7401, that looks like:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Next Header | Header Length |0| Packet Type |Version| RES.|1|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Checksum | Controls|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|Sender's Host Identity Tag (HIT) |
>| |
>| |
>| |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Receiver's Host Identity Tag (HIT) |
>| |
>| |
>| |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| |
>/HIP Parameters /
>/ /
>| |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> The HMAC key is the integrity key for that direction of traffic
> between
> HITs, so the "cross-protocol" part can only come in by confusing the
> packet recipient into confusion as to whether it is processing an
> RVS_HMAC or a RELAY_HMAC (but any other entity will reject the packet
> by
> virtue of it using the wrong key). Modern best practices are to go
> through a key derivation step that incorporates as much information
> as
> possible about what the derived key will be used for, which would in
> this case include the TLV type of the HMAC parameter and presumably
> the
> HITs in question as well.
>
> In particular, the TLV type of the HMAC parameter is *not* input into
> the HMAC calculation (at least for RVS_HMAC), so the trivial
> discriminator is not present. The "packet type" in the header in the
> header is potentially going to differ across usages, so I think
> that's a
> good place to focus discussion. Unfortunately, Section 4.2.1 of RFC
> 8004 suggests that RVS_HMAC is going to be present a lot of the time,
> so
> it's not really clear to me what packet types either RVS_HMAC and/or
> REPLAY_HMAC are expected to occur in. Could a HIP expert please jump
> in
> and help clarify?
let's iterate this further. I think the security concern here is
generic but no specific attack scenario. At this point of
standardization,
I am bit hesitant to do any drastic changes to this unless there is
some
clear attack.
So the parameters can be in the following messages:
*
