[stir] Benjamin Kaduk's Discuss on draft-ietf-stir-passport-divert-08: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 07 April 2020 20:54 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: stir@ietf.org
Delivered-To: stir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 912783A1238; Tue, 7 Apr 2020 13:54:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-stir-passport-divert@ietf.org, stir-chairs@ietf.org, stir@ietf.org, Russ Housley <housley@vigilsec.com>, housley@vigilsec.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.124.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158629284778.13900.16643796031182034257@ietfa.amsl.com>
Date: Tue, 07 Apr 2020 13:54:08 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/zSwKys-LaklAkny7zedcSJKPKwU>
Subject: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-passport-divert-08: (with DISCUSS and COMMENT)
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Apr 2020 20:54:09 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-stir-passport-divert-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-passport-divert/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Roman's Discuss. Isn't there a straightforward translation of the "div" procedures to the nested "div-o" chain? Why would that not be applicable? I had two other points for discussion: (1) IANA seems unhappy (the expert review identified issues). What's the plan to address them? (2) The following text from the Security Considerations seems inconsistent to me: However, including this information about forwarding is at the discretion of the retargeting entity, so if there is a requirement to keep the original called number confidential, no PASSporT should be created for that retargeting - the only consequence will be that downstream entities will be unable to correlate an incoming call with the original PASSporT without access to some prior knowledge of the policies that could have caused the retargeting. I don't understand this -- if the idea is to keep the original called number confidential, wouldn't this necessitate *not giving the original PASSporT to the called entity*, since the original PASSporT includes the original call destination? Without the original PASSporT at all, of course it can't be correlated to an incoming call... (Even in the OOB case, would the post-retargeting called entity even be able to retrieve/decrypt the original PASSporT?) Is this intended to only apply to some non-SIP case? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While it looks like the main change in the -08 is intended to address the secdir reviewer's comment, it would be nice to respond to the review and mention the new text. Do we need to say something about whitespace being added to examples for readability? Section 1 Is there an intended mnemonic for the "opt" element? ("Original passport"?) Do "div-o" PASSporTs necessarily carry both "div" and "opt", or is "opt" intended to be able to stand alone in a "div-o" PASSporT? Section 3 canonical form of the "dest" identifiier is not changed during nit: s/identifiier/identifier/ A "div" PASSporT claims set is populated with elements drawn from the PASSporT(s) received for a call by the retargeting entity: at a high When would there be multiple received PASSporTs that all are input to the same "div" PASSporT? Also, the later discussion that indicates only a small number of claims/extensions are copied from the original PASSporT (and that "iat" might change!) suggests that perhaps the "is populated with" language could be tweaked. level, the original identifier for the called party in the "dest" object will become the "div" claim in the new PASSporT. If the This "will become" language seems a bit problematic when combined with the definition in Section 8 of an "hi" element within the "div" claim, which is not part of the "original identifier for the called party". The combined full form PASSporT (with a signature covered by the ES256 keys given in Appendix A) would look as follows: eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \ oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI \ jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \ 0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE \ J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT \ SqIlk3yCNkg (The decoded claims set is sorted, though the previous display-form example was in a different order.) Section 4 This section specifies SIP-specific usage for the "div" PASSporT type and its handling in the SIP Identity header field "ppt" parameter value. Other protocols using PASSporT may define behavior specific to their use of the "div" claim. Is the last line supposed to be "claim" or "PASSporT type"? Section 4.1 The retargeting entity SHOULD act as a verification service and validate the existing Identity header field value(s) in the request before proceeding; in some high-volume environments, it may instead put that burden of validating the chain entirely on the terminating verification service. As the authentication service will be adding a Is this intended to be the only allowed exception to the SHOULD? (Can we phrase it as a MUST instead, e.g., "except when it is know that the terminating verification service will do so, the retargeting entity MUST act as a verification service"?) PASSporT. Note that this effectively creates multiple chains of "div" PASSporTs in a single request, which complicates the procedures that need to be performed at verification services. [ponders whether there should be more security considerations about these added complications] not for "div" PASSporTs with earlier targets. Ordinarily, the current target will be readily identifiable, as it will be in the last "div" PASSporT in each chain, and in SIP cases it will correspond to the Request-URI received by the retargeting entity. Moreover, the current target will be an identifier that the retargeting entity possess a credential to sign for, which may not be true for earlier targets. Ultimately, on each retargeting, the number of PASSporTs added to a request will be equal to the number of non-"div" PASSporTs that do not share the same "orig" and "dest" object values. We seem to be providing two or three descriptions of the number of new "div" PASSporTs to be created, and it's hard to have full confidence that all are guaranteed to produce identical results. Is it possible to clarify a single definitive procedure? Section 4.2 In order to validate a SIP request using the "div" PASSporT type, a verification service needs to inspect all of the valid Identity header field values associated with a request, as an Identity header field value containing "div" necessarily refers to an earlier PASSporT already in the message. [...] (refers to one or more earlier PASSporT, no?) Deployments that change the original To header field value to conceal the original destination of the call from the ultimate recipient should note that the original destination of a call may be preserved in the innermost PASSporT. [...] Should this also be noted in the security considerations? Section 5 This specification defines a "div-o" PASSporT type that uses the "div" claim element in conjunction with the opt (Section 6) PASSporT claim element. As is the case with "div" PASSporT type, a "div-o" nit: any reason why we refer to "div" as a "claim element" but "opt" (with no quotes!) as a "PASSporT claim element"? Section 6 The presence of an original PASSporT claims set element, designated as "opt", signifies that a PASSporT encapsulates another entire PASSporT within it, typically a PASSporT that was transformed in some way to create the current PASSporT. Relying parties may need to consult the encapsulated PASSporT in order to validate the identity of a caller. "opt" as defined in this specification may be used by future PASSporT extensions as well as in conjunction with "div-o". All the more reason for this document to specify the "div-o" usage's validation procedures! Section 7 an impractical number of combinations. But in very complex call routing scenarios, attestation of source identity would only add limited value anyway. I'm not sure what point this last sentence is trying to make. "Yes this is complicated, but no one would do it anyway"? That doesn't really support the case for retargeting over redirecting... STIR-aware SIP intermediaries that redirect requests MAY therefore convey one or more PASSporTs in the backwards direction within Identity header fields. These redirecting entities will act as authentication services for "div" as described in Section 4.1. This document consequently updates [RFC8224] to permit carrying Identity header fields in SIP 300-class responses. It is left to the originating user agent to determine which Identity header fields should be copied from the 3xx into any new requests resulting from the redirection, if any: use of these Identity header fields by entities receiving a 3xx response is OPTIONAL. Is the idea that making this use optional obviates any need for a negotiation mechanism where the originating user agent indicates support for receiving PASSporTs in the 300-class response? Section 10.1.2 Claim Description: Encapsulated JSON token Is it an encapsulated "JSON token" or "PASSporT [JSON Web Token]"? Section 11 However, as there may be unforeseen circumstances where the revelation of service logic to the called party poses a privacy risk, implementers and users of this or similar diversion-tracking techniques should understand the trade-off. Don't the 300-class redirections also involve some revelation of information to the calling party? I think that could be worth mentioning (though it's not specific to the PASSporT case). Furthermore, it is a general privacy risk of identity mechanisms overall that they do not interface well with anonymization services; the interaction of STIR with anonymization services is detailed in [RFC8224] Section 11. Any forwarding services that acts as an anonymizing proxy may not be able to provide a secure chain of retargeting due to the obfuscation of the originating identity. Isn't there also a risk that an anonymizing proxy might not know to remove all the (information contained in the) PASSporTs, thus inadvertently leaking identity information? Section 12 risk arises at the discretion of the retargeting domain: simply using 3xx response redirections rather than retargeting (with supply a "div" per Section 7) mitigates the potential impact. Under unusual nit: grammar is weird around "with supply a 'div'" Appendix A Thanks for including the keys needed to validate the examples! (Alas, I don't have a JWT or JOSE library handy, so I didn't do so...)
- [stir] Benjamin Kaduk's Discuss on draft-ietf-sti… Benjamin Kaduk via Datatracker
- Re: [stir] Benjamin Kaduk's Discuss on draft-ietf… Peterson, Jon
- Re: [stir] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk