Subject: [stir] WG Last Call comments on stir-oob-04

From: Russ Housley <[email-masked]>
Date: Wed, 17 Apr 2019 11:58:21 -0400

Document: draft-ietf-stir-oob-04.txt
Reviewer: Russ Housley
Review Date: 2019-04-17

Major:

Title page: As discussed on the mail list, please change the 
intended status to "Informational".

Section 11: To date, STIR certificates are only used to digital
signature.  This document suggests that the public key in the
certificate can also be used to provide confidentiality.  This
works if the public key is RSA, and the certificate has the
appropriate key usage bits set.  However, this does not work if
the public key is DSA, ECDSA, Ed25519, or several others.  I
am not asking for a major change to the document, but this
should be pointed out in the document.  And, Section 11 should
point out that finding the credential for the callee cannot
leverage the "x5u" claim in the PASSporT when the public key
can only be used for digital signature.

Minor:

Section 2: Please update the first paragraph to reference RFC 8174
in addition to RFC 2119, as follows: 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
   
Of course, also add a reference to RFC 8174.

The figure in Section 7.2 can be easily adjusted to fit the normal
margins.  Also, the example telephone numbers should use the 555
conventions.  I suggest:

   Alice                    Call Placement Service                  Bob
   --------------------------------------------------------------------

   Store PASSporT for 2.222.555.2222 -->

   Call from 1.111.555.1111 ------------------------------------------>

                                    <-------------- Request PASSporT(s)
                                                     for 2.222.555.2222

                                    Obtain Encrypted PASSporT -------->
                                    (2.222.555.2222, 1.111.555.1111)

                                              [Ring phone with callerid
                                                      = 1.111.555.1111]

Also, adjust the text to reference these example telephone numbers.

Likewise, please adjust the example telephone numbers in Section 9.

It should be equally easy to remove three spaces from the figure in
Section 7.4 to fit the normal margins.

Section 7.3: Please add a reference for TLS.  I assume you will use
[RFC8446].

Section 7.5: s/Sign(K_cps, K_temp))/Sign(K_cps, K_temp)/

Section 11: Please add a reference for OCSP.  I assume you will use
[RFC2560].

Section 14: I think it would be helpful to include pointers to
Sections 7.3 and 7.4 in the Security Considerations.

Nits:

Suggested spelling: s/CPSs/CPSes/  (Note: This spelling is used for
Certificate Practice Statements.)

Section 3: Please spell out the first use of "POTS".  As an alternative,
the sentence could be reworded to use PSTN, which has already been used
many times by this point in the document.

Sections 5.1 and 5.4: s/in the SIP world/in a SIP environment/

Section 5.4: s/back to the IP world/back to a SIP environment/

Section 5.4: s/returns to the IP world/returns to a SIP environment/

Section 5.5: s/a valid calls/a valid call/

Section 6.2: s/one that is valid/one or more that are valid/

Section 7.5: Please add an informative reference on blinded signatures.

---

From: Mary Barnes <[email-masked]>
Date: Thu, 18 Apr 2019 16:02:44 -0500

Just one comment below [MB]

Regards,
Mary.

>    Alice                    Call Placement Service                  Bob
[MB] I agree. [/MB]

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

---

From: Chris Wendt <[email-masked]>
Date: Mon, 22 Apr 2019 23:13:49 -0400

My review of oob document, mostly comments/suggestions/questions.  No major issues since this is a proposed framework vs. protocol specifications.

Abstract - you mentioned other use cases besides non-VoIP protocol, for enterprise scenarios, Should you include brief reference to that style of use-case in abstract?

Introduction - same comment as abstract, it’s very focused on PSTN endpoint bridging, where it might benefit from some other use cases

Section 3 - similar comment, maybe an example of caller (or telephone network) to GW to local specialized network to GW to callee (or telephone network)

Section 4 - is it necessary to describe the two data flow architectures? 

Section 5.5 - this seems like a really specific example, not saying its an invalid example, but just thinking that maybe there is simpler examples to include as well, like a more general thing like enterprise equipment doesn’t support identity headers, enterprise ingress SBC sends passport to CPS, and endpoint has the ability to retrieve the passport when call arrives. for example.

Section 6  - first paragraph "However, as use cases 3 and 4 in Section 5 show” - use case 5 also shows this now

For the rest of the document, I didn’t find any obvious logical issues, obviously this is defining rough details of a potential framework, so nits on interfaces or other details is probably not necessary.

I do agree with other comments that a more explicit note in abstract and/or introduction that this is a proposed framework of architectural elements that are focused on solving the security of issues that are unique to oob stir would be appropriate.

-Chris

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 25 Apr 2019 22:04:08 +0000

Thanks for the notes Russ. A few responses inline.
    
    Major:

    should be pointed out in the document.  

<Jon>This is an artifact of how long the document has been in progress - since before we moved STIR to ECDSA. So, good catch. I do think we should at least sketch a plausible way to get those encryption keys into the architecture. We'll circle around on that and come back with something. </Jon>

    And, Section 11 should
    
<Jon> I'd like to keep the x5u semantics the same in OOB as in-band, definitely, so some change to the text is needed there, agreed. </Jon>
    
    Minor:

       

<Jon> Will do. </Jon>

    

    

    

<Jon> Will fix various margins. The numbers are illegal ones, just illegal in a different way than usual. </Jon>

    

<Jon> Will fix those. </Jon>

<Jon>Yes, I am convinced we need some better Sec Cons text here. And as to nits below, will fix those, thanks. </Jon>
    
    Nits:

    

    

    
Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 25 Apr 2019 22:07:19 +0000

Thanks for the notes Chris. A few responses below:

<Jon> I can add that, sure. </Jon>

<Jon> The references to IP PBXs and terminal adapters there are meant to invoke enterprise and residential VoIP cases, but I can make that more explicit here. </Jon>

<Jon> Again, I think this section is really just showing a higher-level model that is as applicable to local specialized network as it is to callers, we're using caller here as a catch-all for whatever sort of environment the caller might exist in. But I can try to put in some more flavor text about how broadly these architectures should be understood. </Jon>

<Jon> For this sort of architecture/framework document, it's not that uncommon to show your work a bit and explain why you went down one design path instead of another. Since we are (see next comment) teeing up the notification interface, I think it's worth showing both here. </Jon>

<Jon> It's so specific because it's motivating the notification interface which is sketched later. Other enterprise use cases can pretty much be transposed onto the earlier examples - certainly I could patch an enterprise case into something like the flow of 5.2. </Jon>

<Jon> Sure, will do. </Jon>

    
<Jon> Again, will do. </Jon>

    -Chris

Jon Peterson
Neustar, Inc.