Re: [stir] Call For Adoption of draft-peterson-stir-servprovider-oob

[Piotr Gregor <[e-mail]>]

Hi,

In chapter 4 (Advertising CPS) the draft (
https://www.ietf.org/archive/id/draft-ietf-stir-servprovider-oob-01.txt)
says:

   An alternative to CPS advertisements that may be usable in some
   environments is adding a field to STIR [RFC8226] certificates
   identifying the CPS URI issued to individual service providers.  As
   these certificates are themselves signed by a CA, and contain their
   own TNAuthList, the URI would be bound securely to the proper
   telephone network identifiers.  As STIR assumes a community of
   relying parties who trust these credentials, this method perhaps best
   mirrors the trust model required to allow a CPS to authorize
PASSporT submission and retrieval.

It would be quite natural to embed CPS info in provider certificate, but
there is a problem with this: it will work only if the originator of a call
(PASSporT creator) already knows what is the certificate of destination (or
knows where to find it).
This will not be an option if you do not have yet the certificate of the
destination (unless there is other spec wich standardises the certificate
location?).
Maybe it would be a good idea to add a comment on that or elaborate this
section a bit.

regards,
Piotr

On Sun, Sep 27, 2020 at 11:31 PM Peterson, Jon <[e-mail]>
wrote:

>
>
> Thanks for the heads-up, and yes, this has been repaired in the AUTH 48
> process for stir-oob.
>
>
>
> Jon Peterson
>
> Neustar, Inc.
>
>
>
> *From: *Piotr Gregor <[e-mail]>
> *Date: *Monday, August 24, 2020 at 5:09 PM
> *To: *Russ Housley <[e-mail]>
> *Cc: *IETF STIR Mail List <[e-mail]>, "Peterson, Jon"
> <[e-mail]>, Eric Rescorla <[e-mail]>
> *Subject: *Re: [stir] Call For Adoption of
> draft-peterson-stir-servprovider-oob
>
>
>
> I believe there is an error in draft-ietf-stir-oob-07, here in section 9
> it is said that call originates for destination 2.222.555.2222
>
> but then 2.222.222.2222 appears in places I highlighted:
>
>
> 9
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-stir-oob-07*section-9__;Iw!!N14HnBHF!qGWhl_lldmfxuAhX9SKZInSk2i34niQESzkNmAFSMCHw3jkCsoxihluS9UpnvdTjMWlRsw$>.
> Example HTTPS Interface to the CPS
>
>
>
> (...)
>
>    Assume that an authentication service has created the following
>
>    PASSporT for a call to the telephone number 2.222.555.2222
>
> (...)
>
>    Through some discovery mechanism (see Section 10 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-stir-oob-07*section-10__;Iw!!N14HnBHF!qGWhl_lldmfxuAhX9SKZInSk2i34niQESzkNmAFSMCHw3jkCsoxihluS9UpnvdQ2wNRsUA$>), the authentication
>
>    service discovers the network location of a web service that acts as
>
>    the CPS for 2.222.555.2222.
>
> (...)
>
>    Having concluded the numbered steps in Section 8.1 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-stir-oob-07*section-8.1__;Iw!!N14HnBHF!qGWhl_lldmfxuAhX9SKZInSk2i34niQESzkNmAFSMCHw3jkCsoxihluS9UpnvdSkY1ufcw$>, including
>
>    acquiring any token (per Section 6.1 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-stir-oob-07*section-6.1__;Iw!!N14HnBHF!qGWhl_lldmfxuAhX9SKZInSk2i34niQESzkNmAFSMCHw3jkCsoxihluS9UpnvdTPr31zLw$>) needed to store the PASSporT at
>
>    the CPS, the authentication service then stores the encrypted
>
>    PASSporT:
>
>
>
>
>
>
>
> Rescorla & Peterson    Expires September 10, 2020              [Page 20]
>
> ------------------------------
>
>   <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-stir-oob-07*page-21__;Iw!!N14HnBHF!qGWhl_lldmfxuAhX9SKZInSk2i34niQESzkNmAFSMCHw3jkCsoxihluS9UpnvdR0UBsvaQ$>
>
> Internet-Draft              STIR Out-of-Band                  March 2020
>
>
>
>
>
>       POST /cps/2.222.555.2222/ppts HTTP/1.1
>
>       Host: cps.example.com <https://urldefense.com/v3/__http:/cps.example.com__;!!N14HnBHF!qGWhl_lldmfxuAhX9SKZInSk2i34niQESzkNmAFSMCHw3jkCsoxihluS9UpnvdTqcnHCLg$>
>
> (...)
>
>
>
>    The web service assigns a new location for this encrypted PASSporT in
>
>    the collection, returning a 201 OK with the location of
>
>    /cps/2.222.222.2222/ppts/ppt1.
>
> ^^^^^^^^^^^^^^^^^^^^^^
>
> ->>>>>>>>>>>>> should be /cps/2.222.555.2222/ppts/ppt1
>
>
>
>
>
> Now the authentication service can
>
>    place the call, which may be signaled by various protocols.  Once the
>
>    call arrives at the terminating side, a verification service contacts
>
>    its CPS to ask for the set of incoming calls for its telephone number
>
>    (2.222.222.2222).
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> ->>>>>>>>>>>>> should be 2.222.555.2222
>
>
>
>
>
>       GET /cps/2.222.555.2222/ppts
>
>       Host: cps.example.com <https://urldefense.com/v3/__http:/cps.example.com__;!!N14HnBHF!qGWhl_lldmfxuAhX9SKZInSk2i34niQESzkNmAFSMCHw3jkCsoxihluS9UpnvdTqcnHCLg$>
>
>
>
>    This returns to the verification service a list of the PASSporTs
>
>    currently in the collection, which currently consists of only
>
>    /cps/2.222.222.2222/ppts/ppt1.
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> ->>>>>>>>>>>>> should be /cps/2.222.555.2222/ppts/ppt1
>
>
>
>   The verification service then sends a
>
>    new GET for /cps/2.222.555.2222/ppts/ppt1/ which yields:
>
> (...)
>
>
>
> cheers,
>
> Piotr
>
>
>

-- 
Piotr Gregor
Software Engineer
[e-mail]
[phone]

-- 
  *|*  Ask me about SignalWire Work <https://signalwire.com/products/work>, 
our new digital office alternative.