Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2021-02-09
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-08-03
07 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-05-13
07 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-03-10
07 (System) RFC Editor state changed to EDIT
2020-03-10
07 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-03-10
07 (System) Announcement was received by RFC Editor
2020-03-10
07 (System) IANA Action state changed to No IANA Actions from In Progress
2020-03-10
07 (System) IANA Action state changed to In Progress
2020-03-10
07 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-03-10
07 Cindy Morgan IESG has approved the document
2020-03-10
07 Cindy Morgan Closed "Approve" ballot
2020-03-10
07 Cindy Morgan Ballot approval text was generated
2020-03-10
07 Adam Roach IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-03-09
07 Benjamin Kaduk
[Ballot comment]
Thank you for adding the Privacy Considerations section!

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

Section 5.2

  After normal …
[Ballot comment]
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.
2020-03-09
07 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2020-03-09
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-03-09
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-03-09
07 Jon Peterson New version available: draft-ietf-stir-oob-07.txt
2020-03-09
07 (System) New version approved
2020-03-09
07 (System) Request for posting confirmation emailed to previous authors: Eric Rescorla , Jon Peterson
2020-03-09
07 Jon Peterson Uploaded new revision
2020-01-23
06 Adam Roach Per Jon's message at , we'll expect at least one more revision of this document before it moves forward.
2020-01-23
06 Adam Roach IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2019-12-05
06 Alissa Cooper
[Ballot comment]
Thanks for the clarifications about why this is being published as an RFC. It would be good to document those in the shepherd …
[Ballot comment]
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.
2019-12-05
06 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Abstain
2019-12-05
06 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2019-12-04
06 Benjamin Kaduk
[Ballot discuss]
Let's discuss whether we need a standalone privacy considerations
section.  The document obviously does not ignore privacy, and in fact
actively seeks privacy …
[Ballot discuss]
Let's discuss whether we need a standalone privacy considerations
section.  The document obviously does not ignore privacy, and in fact
actively seeks privacy improvements in several places (encrypting
PASSporTs to the recipient's key, blind-signatures for rate-limiting
submission to the CPS, etc.), but it seems like a structured discussion
that considers all the actors and the data flows amongst them might add
significant value.  Given the expected use of TLS and end-to-end
PASSporT encryption, the direct leakage of call information to
intermediaries/observers seems low, and the main risk is in
metadata/correlation attacks that attempt to link submission to the CPS
with initiation and reception of calls, with the CPS representing an
entirely new potential attack point for learning about call information
(in addition to the existing PSTN and SIP infrastructure).  Some avenues
for this have been closed off in the design/architecture presented, but
I don't currently have confidence that all of them have been (to the
extent that the cost/benefit tradeoff remains reasonable).
2019-12-04
06 Benjamin Kaduk
[Ballot comment]
Section 5.2

  After normal PSTN routing, the call lands on a smart mobile handset
  that supports the STIR out-of-band mechanism.  It …
[Ballot comment]
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.
2019-12-04
06 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-12-04
06 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-12-04
06 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-12-04
06 Alissa Cooper
[Ballot comment]
I understand why this document has been useful for the WG to discuss, but I'm unclear on its lasting value as an RFC, …
[Ballot comment]
I understand why this document has been useful for the WG to discuss, but I'm unclear on its lasting value as an RFC, especially with a number of open issues of possible different directions under consideration that are listed in the draft.

Please respond to the Gen-ART review if this document moves forward.
2019-12-04
06 Alissa Cooper [Ballot Position Update] New position, Abstain, has been recorded for Alissa Cooper
2019-12-04
06 Suhas Nandakumar Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Suhas Nandakumar. Sent review to list.
2019-12-04
06 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-12-04
06 Roman Danyliw
[Ballot comment]
Section 7.4.  Per “Callers could store dummy PASSporTs at the CPS at random intervals in order to make it more difficult for an …
[Ballot comment]
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/
2019-12-04
06 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-12-03
06 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

BTW, I second Mirja's question about the doc status. Else, see below for minor …
[Ballot comment]
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?
2019-12-03
06 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-12-03
06 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from No Record
2019-12-03
06 Mirja Kühlewind
[Ballot comment]
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 …
[Ballot comment]
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?
2019-12-03
06 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2019-11-23
06 Watson Ladd Request for Telechat review by SECDIR Completed: Ready. Reviewer: Watson Ladd. Sent review to list.
2019-11-20
06 Tero Kivinen Request for Telechat review by SECDIR is assigned to Watson Ladd
2019-11-20
06 Tero Kivinen Request for Telechat review by SECDIR is assigned to Watson Ladd
2019-11-15
06 Jean Mahoney Request for Telechat review by GENART is assigned to Suhas Nandakumar
2019-11-15
06 Jean Mahoney Request for Telechat review by GENART is assigned to Suhas Nandakumar
2019-11-14
06 Amy Vezza Placed on agenda for telechat - 2019-12-05
2019-11-14
06 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2019-11-14
06 Adam Roach IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2019-11-14
06 Adam Roach Ballot has been issued
2019-11-14
06 Adam Roach [Ballot Position Update] New position, Yes, has been recorded for Adam Roach
2019-11-14
06 Adam Roach Created "Approve" ballot
2019-11-14
06 Adam Roach Ballot writeup was changed
2019-11-04
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-11-04
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-11-04
06 Jon Peterson New version available: draft-ietf-stir-oob-06.txt
2019-11-04
06 (System) New version approved
2019-11-04
06 (System) Request for posting confirmation emailed to previous authors: Eric Rescorla , Jon Peterson
2019-11-04
06 Jon Peterson Uploaded new revision
2019-09-18
05 Adam Roach Waiting for new revision to address input from AD Evaluation, SECDIR review, and GENART review.
2019-09-18
05 Adam Roach IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2019-09-18
05 Adam Roach Changed consensus to Yes from Unknown
2019-09-17
05 Shwetha Bhandari Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Shwetha Bhandari. Sent review to list.
2019-09-17
05 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-09-16
05 Suhas Nandakumar Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Suhas Nandakumar. Sent review to list.
2019-09-13
05 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-09-13
05 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-stir-oob-05, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-stir-oob-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-09-09
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari
2019-09-09
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari
2019-09-06
05 Jean Mahoney Request for Last Call review by GENART is assigned to Suhas Nandakumar
2019-09-06
05 Jean Mahoney Request for Last Call review by GENART is assigned to Suhas Nandakumar
2019-09-05
05 Watson Ladd Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Watson Ladd. Sent review to list.
2019-09-05
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Watson Ladd
2019-09-05
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Watson Ladd
2019-09-03
05 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-09-03
05 Amy Vezza
The following Last Call announcement was sent out (ends 2019-09-17):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, draft-ietf-stir-oob@ietf.org, stir@ietf.org, Robert Sparks , …
The following Last Call announcement was sent out (ends 2019-09-17):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, draft-ietf-stir-oob@ietf.org, stir@ietf.org, Robert Sparks , stir-chairs@ietf.org, rjsparks@nostrum.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (STIR Out-of-Band Architecture and Use Cases) to Informational RFC


The IESG has received a request from the Secure Telephone Identity Revisited
WG (stir) to consider the following document: - 'STIR Out-of-Band
Architecture and Use Cases'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-09-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The PASSporT format defines a token that can be carried by signaling
  protocols, including SIP, to cryptographically attest the identify of
  callers.  Not all telephone calls use Internet signaling protocols,
  however, and some calls use them for only part of their signaling
  path, or cannot reliably deliver SIP header fields end-to-end.  This
  document describes use cases that require the delivery of PASSporT
  objects outside of the signaling path, and defines architectures and
  semantics to provide this functionality.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-stir-oob/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-stir-oob/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-09-03
05 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-09-03
05 Amy Vezza Last call announcement was changed
2019-09-02
05 Adam Roach Last call was requested
2019-09-02
05 Adam Roach Last call announcement was generated
2019-09-02
05 Adam Roach Ballot approval text was generated
2019-09-02
05 Adam Roach Ballot writeup was generated
2019-09-02
05 Adam Roach See AD review at https://mailarchive.ietf.org/arch/msg/stir/cITBna6hUCWmh8rnZoWkYNdIIsE
2019-09-02
05 Adam Roach IESG state changed to Last Call Requested from Publication Requested
2019-07-12
05 Russ Housley Added to session: IETF-105: stir  Mon-1000
2019-07-11
05 Russ Housley
(1) The STIR WG requests publishing draft-ietf-stir-oob as an Informational
    RFC.

(2)

Technical Summary

  The PASSporT format defines a token that can …
(1) The STIR WG requests publishing draft-ietf-stir-oob as an Informational
    RFC.

(2)

Technical Summary

  The PASSporT format defines a token that can be carried by signaling
  protocols, including SIP, to cryptographically attest the identify of
  callers.  Not all telephone calls use Internet signaling protocols,
  however, and some calls use them for only part of their signaling
  path.  This document describes use cases that require the delivery of
  PASSporT objects outside of the signaling path, and defines
  architectures and semantics to provide this functionality.

Working Group Summary

  This document began at the earliest stages of the STIR WG, though many
  participants felt it was a distraction from the core work of the WG and
  asked that focused effort start after the primary in-band work was completed.

Document Quality

  This document has received review from a significant subset of the STIR
  working group.

Personnel

  The document shepherd is Robert Sparks.
  The responsible area director is Adam Roach.

(3) This version of the document is ready for IESG review. The shepherd
    reviewed the document several times in its formation, and did a detailed
    review during the WG second last call.

(4) The document has received attention from several working group participants.
    The depth and breadth of the reviews to date are sufficient for moving the
    document to IESG review.

(5) This document does not require review from specific specialized review teams.

(6) The shepherd has no concerns or issues with this document.

(7) The authors have responded that they are not aware of any needed IPR
    disclosures for previous versions (up through -03). They have been asked
    to reconfirm for the anticipated -05.

(8) There have been no IPR disclosures made against any version of this document.
(9) The consensus to publish this document as an Informational RFC is strong.
    It has received review from a subset of the WG, with others acknowledging
    its existence, and not objecting to its publication.

(10) There has been no threat of appeal raised with respect to this document.

(11) This document passed the shepherd's nits and checklist review. idnits
    complains about some strings (telephone numbers) that it misidentifies
    as IP addresses.

(12) The document contains no sections requiring formal team reviews.

(13) All references within this document been identified as informative.

(14) There are no normative references to be unstable. There are three
    informative references to drafts. One is ~9 years expired, and is
    not expected to be updated.

(15) There are no normative downreferences from this document.

(16) This document does not attempt to change the status of any existing RFCs.

(17) This document requires no actions from IANA.

(17) This document requires no actions from IANA.

(19) This document contains no sections written in a formal language. It does
    contain some example PASSporT objects. The shepherd did not verify these
    were computed correctly. Unlike the protocol specification documents,
    these examples are motivational only. There isn't sufficient information
    in the document to validate them (keys are not given). They are present
    to demonstrate where a given set of bits show up in various messages.

2019-07-11
05 Russ Housley Responsible AD changed to Adam Roach
2019-07-11
05 Russ Housley IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2019-07-11
05 Russ Housley IESG state changed to Publication Requested from I-D Exists
2019-07-11
05 Russ Housley IESG process started in state Publication Requested
2019-07-11
05 Russ Housley Tag Revised I-D Needed - Issue raised by WG cleared.
2019-07-11
05 Russ Housley
(1) The STIR WG requests publishing draft-ietf-stir-oob as an Informational
    RFC.

(2)

Technical Summary

  The PASSporT format defines a token that can …
(1) The STIR WG requests publishing draft-ietf-stir-oob as an Informational
    RFC.

(2)

Technical Summary

  The PASSporT format defines a token that can be carried by signaling
  protocols, including SIP, to cryptographically attest the identify of
  callers.  Not all telephone calls use Internet signaling protocols,
  however, and some calls use them for only part of their signaling
  path.  This document describes use cases that require the delivery of
  PASSporT objects outside of the signaling path, and defines
  architectures and semantics to provide this functionality.

Working Group Summary

  This document began at the earliest stages of the STIR WG, though many
  participants felt it was a distraction from the core work of the WG and
  asked that focused effort start after the primary in-band work was completed.

Document Quality

  This document has received review from a significant subset of the STIR
  working group.

Personnel

  The document shepherd is Robert Sparks.
  The responsible area director is Adam Roach.

(3) This version of the document is ready for IESG review. The shepherd
    reviewed the document several times in its formation, and did a detailed
    review during the WG second last call.

(4) The document has received attention from several working group participants.
    The depth and breadth of the reviews to date are sufficient for moving the
    document to IESG review.

(5) This document does not require review from specific specialized review teams.

(6) The shepherd has no concerns or issues with this document.

(7) The authors have responded that they are not aware of any needed IPR
    disclosures for previous versions (up through -03). They have been asked
    to reconfirm for the anticipated -05.

(8) There have been no IPR disclosures made against any version of this document.
(9) The consensus to publish this document as an Informational RFC is strong.
    It has received review from a subset of the WG, with others acknowledging
    its existence, and not objecting to its publication.

(10) There has been no threat of appeal raised with respect to this document.

(11) This document passed the shepherd's nits and checklist review. idnits
    complains about some strings (telephone numbers) that it misidentifies
    as IP addresses.

(12) The document contains no sections requiring formal team reviews.

(13) All references within this document been identified as informative.

(14) There are no normative references to be unstable. There are three
    informative references to drafts. One is ~9 years expired, and is
    not expected to be updated.

(15) There are no normative downreferences from this document.

(16) This document does not attempt to change the status of any existing RFCs.

(17) This document requires no actions from IANA.

(17) This document requires no actions from IANA.

(19) This document contains no sections written in a formal language. It does
    contain some example PASSporT objects. The shepherd did not verify these
    were computed correctly. Unlike the protocol specification documents,
    these examples are motivational only. There isn't sufficient information
    in the document to validate them (keys are not given). They are present
    to demonstrate where a given set of bits show up in various messages.

2019-07-11
05 Robert Sparks Intended Status changed to Informational from None
2019-07-11
05 Robert Sparks
(1) The STIR WG requests publishing draft-ietf-stir-oob as an Informational
    RFC.

(2)

Technical Summary

  The PASSporT format defines a token that can …
(1) The STIR WG requests publishing draft-ietf-stir-oob as an Informational
    RFC.

(2)

Technical Summary

  The PASSporT format defines a token that can be carried by signaling
  protocols, including SIP, to cryptographically attest the identify of
  callers.  Not all telephone calls use Internet signaling protocols,
  however, and some calls use them for only part of their signaling
  path.  This document describes use cases that require the delivery of
  PASSporT objects outside of the signaling path, and defines
  architectures and semantics to provide this functionality.

Working Group Summary

  This document began at the earliest stages of the STIR WG, though many
  participants felt it was a distraction from the core work of the WG and
  asked that focused effort start after the primary in-band work was completed.

Document Quality

  This document has received review from a significant subset of the STIR
  working group.

Personnel

  The document shepherd is Robert Sparks.
  The responsible area director is Adam Roach.

(3) This version of the document is ready for IESG review. The shepherd
    reviewed the document several times in its formation, and did a detailed
    review during the WG second last call.

(4) The document has received attention from several working group participants.    The depth and breadth of the reviews to date are sufficient for moving the
    document to IESG review.

(5) This document does not require review from specific specialized review teams.

(6) The shepherd has no concerns or issues with this document.

(7) The authors have responded that they are not aware of any needed IPR
    disclosures for previous versions (up through -03). They have been asked
    to reconfirm for the anticipated -05.

(8) There have been no IPR disclosures made against any version of this document.
(9) The consensus to publish this document as an Informational RFC is strong.
    It has received review from a subset of the WG, with others acknowleding
    its existence, and not objecting to its publication.

(10) There has been no threat of appeal raised with respect to this document.

(11) This document passed the shepherd's nits and checklist review. idnits
    complains about some strings (telephone numbers) that it misidentifies
    as IP addresses.

(12) The document contains no sections requiring formal team reviews.

(13) All references within this document been identified as informative.

(14) There are no normative references to be unstable. There are three
    informative references to drafts. One is ~9 years expired, and is
    not expected to be updated.

(15) There are no normative downreferences from this document.

(16) This document does not attempt to change the status of any existing RFCs.

(17) This document requires no actions from IANA.

(17) This document requires no actions from IANA.

(19) This document contains no sections written in a formal language. It does
    contain some example PASSporT objects. The shepherd did not verify these
    were computed correctly. Unlike the protocol specification documents,
    these examples are motivational only. There isn't sufficient information
    in the document to validate them (keys are not given). They are present
    to demonstrate where a given set of bits show up in various messages.

2019-07-11
05 Robert Sparks Notification list changed to Robert Sparks <rjsparks@nostrum.com>
2019-07-11
05 Robert Sparks Document shepherd changed to Robert Sparks
2019-07-08
05 Jon Peterson New version available: draft-ietf-stir-oob-05.txt
2019-07-08
05 (System) New version approved
2019-07-08
05 (System) Request for posting confirmation emailed to previous authors: Eric Rescorla , Jon Peterson
2019-07-08
05 Jon Peterson Uploaded new revision
2019-07-02
04 Robert Sparks Tag Revised I-D Needed - Issue raised by WG set.
2019-07-02
04 Robert Sparks IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2019-03-31
04 Russ Housley Second WG Last Call since significant changes were made.
2019-03-26
04 Robert Sparks Added to session: IETF-104: stir  Fri-0900
2019-03-11
04 Jon Peterson New version available: draft-ietf-stir-oob-04.txt
2019-03-11
04 (System) New version approved
2019-03-11
04 (System) Request for posting confirmation emailed to previous authors: Jon Peterson , Eric Rescorla , stir-chairs@ietf.org
2019-03-11
04 Jon Peterson Uploaded new revision
2019-01-03
03 (System) Document has expired
2018-10-19
03 Robert Sparks IETF WG state changed to In WG Last Call from WG Document
2018-07-02
03 Jon Peterson New version available: draft-ietf-stir-oob-03.txt
2018-07-02
03 (System) New version approved
2018-07-02
03 (System) Request for posting confirmation emailed to previous authors: Jon Peterson , Eric Rescorla
2018-07-02
03 Jon Peterson Uploaded new revision
2018-06-27
02 Russ Housley Added to session: IETF-102: stir  Wed-1520
2018-03-09
02 Russ Housley Added to session: IETF-101: stir  Thu-0930
2018-03-05
02 Jon Peterson New version available: draft-ietf-stir-oob-02.txt
2018-03-05
02 (System) New version approved
2018-03-05
02 (System) Request for posting confirmation emailed to previous authors: Jon Peterson , Eric Rescorla
2018-03-05
02 Jon Peterson Uploaded new revision
2017-10-30
01 Jon Peterson New version available: draft-ietf-stir-oob-01.txt
2017-10-30
01 (System) New version approved
2017-10-30
01 (System) Request for posting confirmation emailed to previous authors: Jon Peterson , Eric Rescorla
2017-10-30
01 Jon Peterson Uploaded new revision
2017-07-16
00 Robert Sparks Added to session: IETF-99: stir  Wed-1330
2017-07-05
00 Robert Sparks This document now replaces draft-rescorla-stir-fallback instead of None
2017-07-03
00 Jon Peterson New version available: draft-ietf-stir-oob-00.txt
2017-07-03
00 (System) WG -00 approved
2017-07-03
00 Jon Peterson Set submitter to "Jon Peterson ", replaces to (none) and sent approval email to group chairs: stir-chairs@ietf.org
2017-07-03
00 Jon Peterson Uploaded new revision