Subject: [ippm] Roman Danyliw's Discuss on draft-ietf-ippm-stamp-option-tlv-07: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 13 Jul 2020 10:12:42 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-ippm-stamp-option-tlv-07: 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-ippm-stamp-option-tlv/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 4.2.  The Location TLV is explicitly trying to extract network
configuration information that would be elided by the first hop router (MAC) or
a NAT (real IP address).  RFC8762 helpfully notes that “When using STAMP over
the Internet … impact of the STAMP-Test packets MUST be thoroughly analyzed.” 
Please provide a bit of text describing the privacy implications here (or bound
this with an applicability statement).

** Section 4.8.  Is the key used for the HMAC TLV the same as the one in the
HMAC in the STAMP authenticated packet?  Could one use different keys?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for responding to the SECDIR review (and thank you to Charlie Kaufman
for doing it).

** Section 4.6.  Per the “ID (Access ID)”, I was a surprised that the values
are hard-coded as this complicates future extensibility (e.g., providing
further fidelity into the type “non-3gpp network” used).  Perhaps this was
intentional to meet the PMF component of TS23501?

** Section 4.8.  This mechanism like, RFC8762, does not provide for algorithm
agility.  As RFC8762 at least says “Future specifications may define the use of
other, more advanced cryptographic algorithms, …” it would be useful to say
that this TLV is anticipated to track updates in the base STAMP protocol.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 14 Jul 2020 16:53:31 -0700

Hi Roman,
thank you for your review, questions, and comments. Please find my answers
below tagged GIM>>.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/
GIM>> You have a valid concern that the Location TLV provides information
on the penultimate to the Session-Reflector router. We can recommend using
the Location TLV either in the STAMP Authenticated mode or in combination
with HMAC TLV. Would that address your concern?

> HMAC in the STAMP authenticated packet?  Could one use different keys?
GIM>> From practical POV, an implementation may choose so that HMAC TLV
will always use the same key as HMAC in the STAMP base packet. But that is
not required as the document leaves the key management outside its scope by
way of reference to Section 4.4 RFC 8762.

GIM>> Indeed, it is how 3GPP defined the PMF. From its POV, any network,
3GPP or Non-3GPP of any kind, that connects to 5GNC uses the same
interfaces and APIs as 3GPP. But that doesn't say that 3GPP may decide to
use other IDs in the future.

> that this TLV is anticipated to track updates in the base STAMP protocol.
GIM>> Agree. Below is the proposed update:
OLD TEXT:
   As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128
   bits ([RFC4868]).  All considerations regarding using the key and key
   distribution and management listed in Section 4.4 of [RFC8762] are
   fully applicable to the use of the HMAC TLV.
NEW TEXT:
    As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128
   bits ([RFC4868]).  All considerations regarding using the key and key
   distribution and management listed in Section 4.4 of [RFC8762] are
   fully applicable to the use of the HMAC TLV.  HMAC TLV is anticipated
   to track updates in the base STAMP protocol [RFC8762], including the
   use of more advanced cryptographic algorithms.