Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases
draft-ietf-stir-oob-07

Section 7.4.  Per “Callers could store dummy PASSporTs at the CPS at random intervals in order to make it more difficult for an eavesdropper to use traffic analysis to determine that a call was about to be placed.”, given the different use cases and possible implementation strategies, I recommend using a different term that “callers” (since it sometimes might be gateways, a new kind of privacy devices which populates the CPS on behalf of a block of numbers it is supposes to protect, etc.).

Section 7.5
       Authenticate to CPS --------------------->
       Blinded(K_temp) ------------------------->
       <------------- Sign(K_cps, Blinded(K_temp))
       [Disconnect]


       Sign(K_cps, K_temp)
       Sign(K_temp, E(K_receiver, PASSporT)) --->


   At an initial time when no call is yet in progress, a potential
   client connects to the CPS, authenticates, and sends a blinded
   version of a freshly generated public key.  The CPS returns a signed
   version of that blinded key.  The sender can then unblind the key and
   gets a signature on K_temp from the CPS.

Recommend the following editorial clarifications to explain this flow:

- s/and sends a blinded version of a freshly generated public key/and sends a blinded version of a freshly generated public key (i.e., K_temp)/ (maybe do that for other flow elements as well, or number the follows to allow easy reference in the text)

- The K_cps depicted in the flow diagram is not explained in the text (i.e., the public key of the CPS?)

- The K_receiver depicted in the follow diagram is not explained in the text

- s/Sign(K_cps, K_temp)/Sign(K_cps, K_temp) ------------->/

- Somehow visual distinguish in the flow diagram that the signing key of “Sign(K_cps …)” is different than “Sign(K_temp, E(K_receiver …”

Section 7.5.  Per “Then later, when a client wants to store a PASSporT, it connects to the CPS anonymously (preferably over a network connection that cannot be correlated with the token acquisition)”, are there recommended strategies to realize non-attributed and attributed use cases across the use cases?

Section 8.1.  Per Step 2, this text provides an example of “out-of-band applications built-in to the calling device”, which covers only a subset of the use cases in Section 5 (i.e., UC1, 2 and 4?)  Can anything be said about the other use cases?

Section 9.  Given that this document is notionally just laying out use cases, a high-level architecture, and high-level design considerations, this section seems to cross deep into a notional solution without all of the details outlined in the previous section.  I would recommend removing it.

* Editorial Nits:
- Section 1.  s/But while the core/While the core/
- Section 1.  s/Then techniques/The techniques/
- Section 4.  s/it is here specified generically/it is specified here generically/
- Section 7.  Colloquial language.  s/sketchy/vague/
- Section 7.4. Editorial.  s/All that receipt/All the receipt/

Thank you for the work put into this document. 

BTW, I second Mirja's question about the doc status. Else, see below for minor COMMENTs.

Regards,

-éric

== COMMENTS ==

-- Section 4 --
It is really unclear to me how the system could work if there is no discovery mechanisms for the CPS (even if section 10 is devoted to discovery). Else, I am fearing having one CPS per smart phone OS or any other fragmentation...

-- Section 6 --
" transport-level security can provide confidentiality from eavesdroppers for both the storage", while I agree that TLS provides confidentiality for eavesdroppers, I wonder how it can protect the storage (data at rest) ? Or am I reading the sentence incorrectly ?

-- Section 7.4 --
Should this section "Substitution Attacks" be a sub-section of section 7.3 "Security Analysis" ?

In the time diagram, it is not clear at reading the figure what CS stands for (need to read the text below) also unclear who is initiating 'Call from CS': is it the attacker?

Thanks for the clarifications about why this is being published as an RFC. It would be good to document those in the shepherd write-up.

Please respond to the Gen-ART review if this document moves forward.

Thank you for adding the Privacy Considerations section!

My original comments from the -06 are retained below, unchanged.

Section 5.2

   After normal PSTN routing, the call lands on a smart mobile handset
   that supports the STIR out-of-band mechanism.  It queries the
   appropriate CPS over the Internet to determine if a call has been

How might "the appropriate CPS" be determined?  (Is just linking to
Section 10 the right thing to do?)

Section 7.3

   2.  The attacker wishes to substitute himself for an existing call
       setup as described in Section 7.4.

   If an attacker can inject fake PASSporT into the CPS or in the
   communication from the CPS to the callee, he can mount either attack.

   As PASSporTs should be digitally signed by an appropriate authority
   for the number and verified by the callee (see Section 7.1), this
   should not arise in ordinary operations.  For privacy and robustness

Doesn't the substitution attack in the following section count as
achieving (2)?  And in general, couldn't an attacker always race with
any legitimate call?

Section 7.4

We don't specify what 111.555.1111 corresponds to before we use it in
the example.

   In order to prevent a passive attacker from using traffic analysis or
   similar means to learn precisely when a call is placed, it is
   essential that the connection between the caller and the CPS be
   encrypted as recommended above.  Callers could store dummy PASSporTs
   at the CPS at random intervals in order to make it more difficult for
   an eavesdropper to use traffic analysis to determine that a call was
   about to be placed.

Not just encrypted, but potentially persistent, too?  I guess that only
makes sending the dummy traffic cheaper, but doing it non-persistently
is not impossible.

Section 7.5

We should note that K_cps should be limited to *only* be valid for
signing these specific tokens, to avoid having a signing oracle that
could be used for nefarious purposes.  (Either here or in the security
considerations.)

       Sign(K_cps, K_temp)

Isn't this more of an "unblind" operation than a "sign" one, given that
"Sender" shouldn't know K_cps?

Section 9

The timestamps in these examples are kind of old at this point; do we
want to refresh them to be closer to the time of publication?

   Assume that an authentication service has created the following
   PASSporT for a call to the telephone number 2.222.555.2222 (note that
   these are dummy values):

      eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j
      ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InVyaSI6WyJz
      aXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDMyMDgzNDUiLCJvcmlnI
      jp7InRuIjoiMTIxNTU1NTEyMTIifX0.rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1
      VOgFWSjHBr8Qjpjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w

Er, is the destination 2.222.555.2222 or sip:alice@example.com?

   Having concluded the numbered steps in Section 8.1, including
   acquiring any token (per Section 6.1) needed to store the PASSporT at
   the CPS, the authentication service then stores the encrypted
   PASSporT:

      POST /cps/2.222.555.2222/ppts HTTP/1.1
      Host: cps.example.com
      Content-Type: application/passport

      rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
      MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
      nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
      wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
      IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j

Is it really appropriate to use the "application/passport" media type
for an encrypted PASSporT?

   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.  Now the authentication service can

Should we consider the potential information leakage from sequential URL
components?  Perhaps randomized path components are better.

Section 11

   It is a desirable property that the public encryption key for a given
   party be linked to their STIR credential.  We therefore propose that
   an ECDH [RFC7748] public-private key pair be generated for a subcert
   [I-D.ietf-tls-subcerts] of the STIR credential.  That subcert could

It seems a bit premature to phrase this as "We therefore propose" given
that the rest of our speculative discusions have been generic in nature.

I don't really understand why this document is requested to be published as informational and the shepherd write-up unfortunately doesn't provide any additional information about this decision, so I have to ask: I understand that the http-based protocol is meant only as an example protocol but how can such a scheme ever get deployed if there is not even a uniform protocol specified that a callee or caller can use to retrieve the needed information? If the group isn't sure about the the protocol selection yet, publishing this as experimental in order to get some experience with its deployment seems to be appropriate. However with the informational document right now (any only the example protocol), there is no guarantee for interoperability and I don't see how any test deployment could even happen. So what's the intention here?