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 |