Subject: [Gen-art] Genart last call review of draft-ietf-stir-passport-shaken-04

From: Francesca Palombini <[email-masked]>
Date: Fri, 02 Nov 2018 09:14:47 -0700

Reviewer: Francesca Palombini
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-stir-passport-shaken-04
Reviewer: Francesca Palombini
Review Date: 2018-11-02
IETF LC End Date: 2018-11-02
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is on the right track but has open issues, described in the
review.

Major issues:

* This draft defines the new claim "origid" for the Personal Attestation Token
used in the SHAKEN framework, but does not give any privacy considerations
about it and its use. [RFC6973] suggests that the privacy considerations of
IETF protocols be documented. As required by [RFC7258], work on IETF protocols
needs to consider the effects of pervasive monitoring and mitigate them when
possible. I don't know SHAKEN well enough to comment on privacy issues on that,
but this draft, as part of the IETF work, should have privacy considerations,
particularly considering the "origid" claim.

Minor issues:

* Section 4: the term "verified association" is not defined in this document,
nor in [RFC8225], nor in the SHAKEN spec referenced. Is there a way to clarify
what is meant by it? It could be a reference.

Nits/editorial comments:

* Terminology: I would have appreciated a short sentence mentioning [RFC8225]
in the Terminology section.

* Section 9: [RFC8224] appears without link.

* Acknowledgements: "The authors would like
   acknowledge the work of the ATIS/SIP Forum IP-NNI Task Force to
   develop the concepts behind this document." -> The authors would like to
   acknowledge ...

I do not repeat nits and editorials reported by Adam Roach in his review of
this version of the document (11-19-2018,
https://mailarchive.ietf.org/arch/msg/stir/HxVSCLPGfSgwFuvqLkWSVNI0PtQ )

---

From: Chris Wendt <[email-masked]>
Date: Sun, 4 Nov 2018 07:55:16 -0500

Thank Francesca for the review.  Comments inline.

> On Nov 2, 2018, at 12:14 PM, Francesca Palombini <[email-masked]> wrote:
> 

Here is my proposed privacy consideration section, looking for any comments if this addresses things properly given the nature of SIP privacy in general.

Privacy Considerations 

As detailed in {{RFC3261}} Section 26 as well as {{RFC3323}}, SIP as a protocol inherently carries identifying information of both the initiator or 'caller' as well as the terminating party or 'callee'. 'origid', as defined in SHAKEN {{ATIS-1000074}} and described in this document is intended to be an opaque and unique identifier that is used by an originating telephone service provider to trace and identify where within their network (e.g. from a gateway or a particular service within their network) the call was initiated, so that either bad actors that may be either trying to illegitamately spoof identities or making fraudulent calls can be identified and likely stopped or held responsibiliy for the fraudulent activities.  While the opaqueness of the 'origid' identifier is intended to keep any direct or implied information regarding the origination of a set of calls that may have the same 'origid' to a minimum, it should be recognized that potential patterns whether intended or not may be able to be discovered.

> what is meant by it? It could be a reference.

I’ve included a new terminology text as follows to address above comment and comment below:

   In addition, the following terms are used in this document:

   o  Verified association: is typically defined as an authenticated
      relationship with a device that initiated a call, for example, a
      subscriber account with a specific SIM card or set of SIP
      credentials.

   o  PASSporT: Defined in [RFC8225] is a JSON Web Token defined
      specifically for securing the identity of an initiator of personal
      communication.  This document defines a specific extension to
      PASSporT.

> in the Terminology section.

see above

> * Section 9: [RFC8224] appears without link.

fixed

>   acknowledge …
fixed

> https://mailarchive.ietf.org/arch/msg/stir/HxVSCLPGfSgwFuvqLkWSVNI0PtQ )

I have addressed these issues and plan to submit with list consensus on above text.

---

From: Francesca Palombini <[email-masked]>
Date: Mon, 5 Nov 2018 02:48:59 +0000

Thanks Chris, these changes address my review comments.

Francesca

On 04/11/2018, 19:55, "Chris Wendt" <[email-masked]> wrote:

    
    Privacy Considerations 

    

    

    see above

    fixed
    
    fixed

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 20 Nov 2018 16:25:35 -0500

Francesca, thanks for your review. All, thanks for addressing Francesca’s comments. I entered a No Objection ballot but I think there is more to say about the privacy implications of origids — to be discussed in the thread about Eric’s ballot.

Thanks,
Alissa

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art