[Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Tue, 22 May 2018 13:48 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBE4127078; Tue, 22 May 2018 06:48:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dime-rfc4006bis@ietf.org, Jouni Korhonen <jouni.nospam@gmail.com>, dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.80.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com>
Date: Tue, 22 May 2018 06:48:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/dqbzGyyEJeMc9JeRdBsCyF6O3EE>
Subject: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 May 2018 13:48:23 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-dime-rfc4006bis-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-dime-rfc4006bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Alissa's Discuss point about sensitive AVPs. I appear to have a different understanding of Section 5.6.2, though, with a different potential issue (but again, it's possible that I'm confused to how things work): With the redirection schemes covered in Section 5.6.2, it sounds like the user can be redirected (at the application protocol level, e.g., HTTP or SIP) to a top-up server to purchase more credits. I don't see a way described how user agents can distinguish between a Diameter-induced redirect and an attacker-induced redirect to a (potentially phishing) site that accepts payment information. To be clear, the scenario here is that a user is using a credit-controlled application session to talk to "arbitrary application servers", including potentially attacker-controllled HTTP/SIP/etc. servers; the attacker could introduce a redirect to a phishing page that asks for payment information, and the user would be led to believe that this was the normal flow for "my prepaid balance has been used up", and give their payment information to the phishing site. I think that either user agents need to give some indication that this DIAMETER-level redirect is different than an application-protocol-level redirect (e.g., http) or the Security Considerations need to mention the risk of acclimating users to arbitrary websites redirecting to sites asking for payment credentials, which may or may not be legitimate sites. Separately, in Section 8.68 (for QoS-Final-Unit-Indication): If the Final-Unit-Action AVP is set to REDIRECT at least the Redirect-Server-Extension AVP MUST be present. This MUST seems in conflict with the text in 8.64 (actually, is section 8.64 even internally inconsistent, too?) about "Redirect-Server AVP, in addition to or instead of the Redirect-Server-Extension AVP", in particular, the "instead of" portion. (The ABNF-based formal language spec in 8.68 does match up with the above MUST, though.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some additional significant but not necessarily DISCUSS-worthy comments, followed by more editorial- and nit-level things. In Section 1.3, "Advertising Application Support" uses the same Auth-Application-ID value as for RFC 4006; what are the interop consequences of this? Alissa already noted that the text about how to split (sub-)AVPs between the foo and foo-Extension AVPs is inconsistent among them -- e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD send [in the old one]", but Subscription-Id-Extension has separate text about "[i]f full backward compatibility with [RFC4006] is required" and slightly different behavior described. We should try to catch all instances of this sort of backwards compatibility and make them consistent. The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL) might benefit from additional text about the expected contents. A lot of the time when we use a UTF8 container for names (whether domain names or other kinds), we specify what normalization form and canonicalization are performed, whether domain names are A-labels or U-labels, etc., as there's a lot of potential flexibility not all of which is good. In this case, since the communication is only between trusted actors, perhaps the additional restrictions are not needed, but I am curious if the topic was raised in the WG. Thank you for adding the Privacy Considerations and list of Privacy-Sensitive AVPs! Section 14 [...] The Diameter credit- control application is often used within one domain, and there may be a single hop between the peers. In these environments, the use of TLS/TCP, DTLS/SCTP or IPsec is sufficient. I did not see any concrete guidance on what would suffice in other environments (with multiple hops between peers). Is this the realm of the mythical "end-to-end security mechanism" for Diameter that is much-desired? (The last paragraph does have guidance on what might *not* suffice, which is not exactly the same thing.) Even without any modification to the messages, an adversary can eavesdrop on transactions that contain privacy-sensitive information about the user. This ("an adversary can") makes it sounds as if there is no confidentiality protection anywhere in the system, but that's what TLS/DTLS/IPSec are supposed to provide. So maybe "an adversary that can eavesdrop on transactions can obtain privacy-sensitive information [...]" is better. (Editorial- and nit-level stuff follows.) Section 4 A flexible credit-control application specific failure handling is defined in which the home service provider can model the credit- control client behavior according to its own credit risk management policy. This sentence is hard to parse -- in "credit-control application specific" what does "specific" bind to? What is being modelled? Is anything being controlled (as opposed to modelled)? Section 4.1.1 2. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g., ASN.1 BER). [...] Why BER and not DER? The unnecessary flexibility in BER vs. DER has been known to tickle parser bugs and create security vulnerabilities. Section 4.1.2 [...] To facilitate interoperability, it is RECOMMENDED that the rating input and the values of the Service-Context-Id be coordinated via an informational RFC or other permanent and readily available reference. The specification of another cooperative standardization body (e.g., 3GPP, OMA, or 3GPP2) SHOULD be used. The RECOMMENDED and SHOULD seem slightly in conflict. Section 5.1.1 As noted elsewhere, 60 seconds per minute does not always hold; it seems that this text could be reworded to just talk about a "constant rate" or "constant level per fixed time period" or similar. Section 5.1.2 [...] timer (Section 13) every time a CCR message with the value UPDATE_REQUEST is sent while they are in PendingU state. When answers to all pending messages are received, the state machine moves to OPEN state, and Tx is stopped. Transmission, or the Tx timer (is stopped)? Using a different title for Section 5.2.2 might make the parallel between it and Section 5.2.1 more clear. That is, perhaps something like "First Interrogation Included with Authorization Messages". Section 5.7 [...] It is RECOMMENDED that the client complement the credit- control failure procedures with backup accounting flow toward an accounting server. [...] Nit: it looks like there's a missing article here, maybe "a backup accounting flow" is better. The AAA transport profile [RFC3539] defines the application layer watchdog algorithm that enables failover from a peer that has failed and is controlled by a watchdog timer (Tw) defined in [RFC3539]. Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm? Section 6.2 Should there be text indicating how the client indicates what service the balance check is being requested for? Section 8.54 Maybe give a section reference in RFC 3580 for how the formatting is done? Section 12 [...] Initially, such Expert discussions take place on the AAA WG mailing list. That list appears to be dead, suggesting that this text should be updated. (I also agree with Adam's comments about updating the IANA Considerations.) Why is the disclaimer in Section B.4 (and other examples) not needed in Section B.3?
- [Dime] Benjamin Kaduk's Discuss on draft-ietf-dim… Benjamin Kaduk
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Ben Campbell
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Yuval Lifshitz
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Yuval Lifshitz
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Ben Campbell
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Ben Campbell
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Yuval Lifshitz
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Yuval Lifshitz
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf… Yuval Lifshitz