From nobody Sat Jul 14 15:22:02 2018 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7DC130F16; Sat, 14 Jul 2018 15:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fL27606nqz2E; Sat, 14 Jul 2018 15:21:58 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524D4130E6E; Sat, 14 Jul 2018 15:21:55 -0700 (PDT) X-AuditID: 12074424-92fff70000002712-f7-5b4a77829752 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id AF.EA.10002.2877A4B5; Sat, 14 Jul 2018 18:21:54 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w6EMLqkh009345; Sat, 14 Jul 2018 18:21:53 -0400 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w6EMLnYK002750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Jul 2018 18:21:51 -0400 Date: Sat, 14 Jul 2018 17:21:49 -0500 From: Benjamin Kaduk To: draft-ietf-radext-coa-proxy.all@ietf.org Cc: radext@ietf.org Message-ID: <20180714222148.GP59001@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixCmqrdtU7hVt0DxB3OL8m//sFi2vZrI5 MHksWfKTKYAxissmJTUnsyy1SN8ugStj6r+1zAXLrSpWN+9lbGD8pdfFyMkhIWAi8aTxK1sX IxeHkMBiJok1ixpZIZyNjBLTZuyEcs4yScz/sJ8ZpIVFQFXizbZWdhCbTUBFoqH7MlhcREBH 4s6iqywgNrOAsMTGU+uZQGxhATuJ/q0Twep5gWo6DnUyQ9iCEidnPoGq15K48e8lUD0HkC0t sfwfB0hYVEBZYm/fIfYJjHyzkHTMQtIxC6FjASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1z vdzMEr3UlNJNjKBgY3dR2cHY3eN9iFGAg1GJh7fCxitaiDWxrLgy9xCjJAeTkijvZSGgEF9S fkplRmJxRnxRaU5q8SFGCQ5mJRHeVeJAOd6UxMqq1KJ8mJQ0B4uSOG/uIsZoIYH0xJLU7NTU gtQimKwMB4eSBG9rGVCjYFFqempFWmZOCUKaiYMTZDgP0PA9IDW8xQWJucWZ6RD5U4zGHC8W 9Uxi5vjzfuokZiGWvPy8VClx3nqQUgGQ0ozSPLhpoIQhkb2/5hWjONBzwrxzQap4gMkGbt4r oFVMQKv0OjxBVpUkIqSkGhiVzIM3JzDcVHlXliO6Umw+S5Rrh8as+5HJu7fMMmU4tcij2u+K 12Snztkyj048inmxJD/2Ysrh2bNdNJSllSYz1QT+/O5+ja1N89/JtRPeNP1YkmKobNdnqp53 917dgtOXt/rwr5181ihqiflhpdPhq49uVFrbMuPXA5aPcdHyfn/+7jwgXLFNiaU4I9FQi7mo OBEAcYB6nvMCAAA= Archived-At: Subject: [radext] (belated) AD review of draft-ietf-radext-coa-proxy-04 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 22:22:00 -0000 Apologies for the long delay on this one; I had written up an AD review a month or two ago but it got lost in the ether. I've tried to reconstruct my comments based on notes I made on a paper printout, so there will be a few places where I imply that I changed my mind since the initial review. I have a couple of concerns about this document that I think should be resolved before I move it into IETF Last Call: This document lists RFC 5176 and RFC 2866 as informative references, possibly so as to avoid the awkwardness of a standards-track document making a normative downreference to informational documents. I think that at least RFC 5176 should be a normative reference, since it really must be understood in order to implement this document -- after all, we even Update it! Looking back again (for the third time, actually), it's less clear that the RFC 2866 reference is actually as problematic as it seemed on first read; as there is only a single reference and it is just explaining why this document has a MUST-level requirement. I don't think there's an actual issue with making 5176 a normative reference in terms of process; we just have to call out the "downref" during IETF Last Call and then it goes on the list of approved downrefs. I also think there needs to be some more clarity in the Requirements on Visited Networks (Section 4.2), in several ways: * First off, it refers to "all the checks discussed above for proxies", which presumatly is an artifact of subsection reordering. Even if it is changed to "below", though, I'm still unclear on exactly which checks are implied -- is this just the filtering from Section 4.3.2? * Furthermore, it's unclear what it actually means to have a MUST-level requirement to do some checks that are only SHOULD-level in Section 4.3.2. * I'm also a little fuzzy on where thse requirements apply, as a "Visited Network" is kind of a fuzzy concept, and is going to potentially involve things like a network perimeter/firewall, some form of proxies, RADIUS servers, etc. -- should we say something more specific about where the actions to meet these requirements will be taken? * I don't think I followed how assuming there's a proxy between the NAS and any external proxy implied a requirement for the Visited Network to perform "all of the checks". (Maybe if what the checks were was clarified this concern would go away, though.) * The second paragraph leaves me generally confused, mostly in that it is talking about somethinf "phrased more generically in Section 4.3.2", which is my best guess for the thing that the first paragraph is trying to require. So is this whole paragraph redundant? * Why is the cryptographically-strong requirement for Operator-NAS-Identity only SHOULD and not MUST? * Is there a conflict between the "without requiring to track ... in a database" in the third paragraph, and the text for the Value field in the Operator-NAS-Identifier definition, that says "either track these tokens in a database, or [...] create tokens which can be decoded"? I also think this document should probably switch over to the RFC 8174 boilerplate instead of the RFC 2119 boilerplate, if only to save all of the IESG and the genart reviewer from having to comment about it. Somewhat editorial, but with great potential for confusion: in Section 3.3, please insert text like "The new Operator-NAS-Identifier attribute is defined as follows" before the Description/Type/etc. Also in Section 3.3, I wondered if the "in practice" clarification for using a database or self-encrypted tokens was intentionally excluding the possibility of always using the same value for the token (e.g., if there is only one NAS in the Visited Network, which is admittedly unlikely in nontrivial deployments). Some editorial comments follow. As a general comment, the RFC Editor generally likes to distinguish between "which" (inate attributes that apply to all elements of a class) and "that" (attributes that only apply to a subset of the class, and thereby specifying a new restriction on what is being discussed). I don't really have a horse in the race, but if you want to avoid getting asked about it later, you could make a pass over the document looking for them. There's a couple spots in Section 4.3.1 that would probably change from "which" to "that", if you do. In Section 1, I think the second paragraph should start with "We partially correct" given the limitation made in the third paragraph. I might also reword the third paragraph to something like "This correction is limited to the use case of CoA proxying Realm-basec proxying [...]", as it's not exactly the use case that's being limited as much as the applicability of this document. (It looks like I had originally suggested reordering the second and third paragraphs, but that doesn't make sense to me now.) In Section 2.1, fourth paragraph, it may be useful to clarify whether "The RADIUS client" applies only to the endpoint (non-proxy) client or to the client portion of all entities participating in a proxy chain along the path. In Section 2.3, "there may be a different CoA server which could accept the packet", I assume that "accept the packet" is supposed to imply "and do something useful with it"; perhaps this could be reworded to something like "successfully process the packet". Additionally, it doesn't seem accurate to say that 5176 "is silent on the topic of 'session identification attributes'", since that phrase appears ten times; it seems like we are saying that it doesn't actually tell you how to use them or what they are, but just says that they can exist (kind of like the situation for CA proxying itself). The pedant in me takes issue with "impossible" in "impossible to send CoA packets to the Visited Network", in Section 3.1 -- I assume that there are other contrived and inefficient potential solutions. s/one ore more/one or more/ in Section 3.2 In Section 3.3, third paragraph, the references to 2865 and 2866 are both Section 4.1; we should probably say both "Section 4.1 of [2865], and of Section 4.1 of [2866]. It also seems that a reference to Section 4.1 (what a coincidence!) of RFC 5580 might be in order, to note the parallelism between Operator-NAS-Identifier and Operator-Name. In Section 4.2, third paragraph, presumably the non-requirement for tracking in a database "every individual value" applies only to those values that are actually issued. (That is, I'm asking to add "issued," in "every value of Operator-NAS-Identifier issued, in a database".) In Section 4.3.2, do we want to "specifically note" or "call out" instead of just "note" that the above requirements apply to future attributes added by a proxy (as well as the ones defined here)? (This is something of a style question, so it's up to you.) Section 5.1, s/xwill/will/ In the last paragraph of Section 5.1, do we need to say that the recording is done "if present"? Section 5.2, s/disconnecte/disconnected/; s/recieve/receive/; s/fromt he/from the/ Also in Section 5.2, do we want to add "next-hop" when talking about finding "the CoA server for that realm"? And, in the last paragraph, we say "Any response from the CoA server [...]", but isn't the CoA server required to send such a response? -Ben From nobody Sun Jul 15 06:52:58 2018 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F755130DD1; Sun, 15 Jul 2018 06:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fQNZJBNDGjH; Sun, 15 Jul 2018 06:52:53 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id E3AA51271FF; Sun, 15 Jul 2018 06:52:52 -0700 (PDT) Received: from [192.168.46.58] (198-84-237-221.cpe.teksavvy.com [198.84.237.221]) by mail.networkradius.com (Postfix) with ESMTPSA id 5608A109; Sun, 15 Jul 2018 13:52:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <20180714222148.GP59001@mit.edu> Date: Sun, 15 Jul 2018 09:52:56 -0400 Cc: draft-ietf-radext-coa-proxy.all@ietf.org, radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180714222148.GP59001@mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] (belated) AD review of draft-ietf-radext-coa-proxy-04 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 13:52:55 -0000 On Jul 14, 2018, at 6:21 PM, Benjamin Kaduk wrote: > This document lists RFC 5176 and RFC 2866 as informative references, > possibly so as to avoid the awkwardness of a standards-track document > making a normative downreference to informational documents. I think = that > at least RFC 5176 should be a normative reference, Sure. > I also think there needs to be some more clarity in the Requirements = on > Visited Networks (Section 4.2), in several ways: >=20 > * First off, it refers to "all the checks discussed above for = proxies", > which presumatly is an artifact of subsection reordering. Even if it = is > changed to "below", though, I'm still unclear on exactly which checks = are > implied -- is this just the filtering from Section 4.3.2? Yes. > * Furthermore, it's unclear what it actually means to have a = MUST-level > requirement to do some checks that are only SHOULD-level in Section > 4.3.2. 4.3.2 has a few MUST requirements. The text could say: A Visited Network which receives a CoA packet which will be proxied MUST = perform all of the operations required for proxies by Section 4.3.2.=20 > * I'm also a little fuzzy on where thse requirements apply, as a = "Visited > Network" is kind of a fuzzy concept, It's a common term in RADIUS. See RFC 7542: https://tools.ietf.org/html/rfc7542 In short, you have a "home" network. This is the network managed by = the people who gave you your account. A "visited" network is where you = use your "home" credentials to visit someone else's network. > and is going to potentially involve > things like a network perimeter/firewall, some form of proxies, = RADIUS > servers, etc. -- should we say something more specific about where = the > actions to meet these requirements will be taken? I don't think so. Most of these actions are administrative and/or = contractual. i.e. can a AT&T user roam onto Verizon's network? Answer: = ask the lawyers. :) The other technical details are necessary, but don't affect RADIUS = here. We just require that (magically) the RADIUS servers can exchange = packets. > * I don't think I followed how assuming there's a proxy between the = NAS and > any external proxy implied a requirement for the Visited Network to > perform "all of the checks". (Maybe if what the checks were was > clarified this concern would go away, though.) The assumption is that the visited NAS doesn't send packets directly = to the home RADIUS server. Instead, the visited NAS sends packets to = it's local RADIUS server: the visited RADIUS server. That one goes "oops, not my user.." and proxies the packet. So it's a = proxy, and all of the proxy rules apply. The text is there because otherwise people might think that the proxy = rules only apply for "proxy to proxy" packets. > * The second paragraph leaves me generally confused, mostly in that it = is > talking about somethinf "phrased more generically in Section 4.3.2", > which is my best guess for the thing that the first paragraph is = trying > to require. So is this whole paragraph redundant? It's largely a reminder to that the Operator-Name attribute is for = server to server signalling. The NAS doesn't know anything about it, so = you should never send it to the NAS. It's redundant, but IMHO a useful reminder. > * Why is the cryptographically-strong requirement for = Operator-NAS-Identity > only SHOULD and not MUST? It could be a simple incrementing counter, with the visited network = tracking counter to NAS packets. Yes, implementations are that dumb. > * Is there a conflict between the "without requiring to track ... in a > database" in the third paragraph, and the text for the Value field in = the > Operator-NAS-Identifier definition, that says "either track these = tokens > in a database, or [...] create tokens which can be decoded"? I don't think so. If the operator tracks the values in a DB, those = values don't need to be cryptographically strong. If the operator "hides" the real NAS identity in a signed / encrypted = value, then that "hiding" method should be cryptographically strong. Perhaps it could be worded more clearly. > I also think this document should probably switch over to the RFC 8174 > boilerplate instead of the RFC 2119 boilerplate, if only to save all = of the > IESG and the genart reviewer from having to comment about it. Sure. > Somewhat editorial, but with great potential for confusion: in Section = 3.3, > please insert text like "The new Operator-NAS-Identifier attribute is > defined as follows" before the Description/Type/etc. Sure. > Also in Section 3.3, I wondered if the "in practice" clarification for > using a database or self-encrypted tokens was intentionally excluding = the > possibility of always using the same value for the token (e.g., if = there is > only one NAS in the Visited Network, which is admittedly unlikely in > nontrivial deployments). No, that's a permitted use-case. I'll add a comment for "non-trivial = use-cases". > Some editorial comments follow. >=20 > As a general comment, the RFC Editor generally likes to distinguish = between > "which" (inate attributes that apply to all elements of a class) and = "that" > (attributes that only apply to a subset of the class, and thereby > specifying a new restriction on what is being discussed). I don't = really > have a horse in the race, but if you want to avoid getting asked about = it > later, you could make a pass over the document looking for them. = There's a > couple spots in Section 4.3.1 that would probably change from "which" = to > "that", if you do. Sure. I'll take a look. > In Section 1, I think the second paragraph should start with "We = partially > correct" given the limitation made in the third paragraph. Yes. > I might also > reword the third paragraph to something like "This correction is = limited to > the use case of CoA proxying Realm-basec proxying [...]", as it's not > exactly the use case that's being limited as much as the applicability = of > this document. (It looks like I had originally suggested reordering = the > second and third paragraphs, but that doesn't make sense to me now.) OK. > In Section 2.1, fourth paragraph, it may be useful to clarify whether = "The > RADIUS client" applies only to the endpoint (non-proxy) client or to = the > client portion of all entities participating in a proxy chain along = the > path. It applies to the client portion of all RADIUS transactions. That = should be clarified by the subsequent sentence in that paragraph. > In Section 2.3, "there may be a different CoA server which could = accept the > packet", I assume that "accept the packet" is supposed to imply "and = do > something useful with it"; perhaps this could be reworded to something = like > "successfully process the packet". Yes. > Additionally, it doesn't seem accurate > to say that 5176 "is silent on the topic of 'session identification > attributes'", since that phrase appears ten times; it seems like we = are > saying that it doesn't actually tell you how to use them or what they = are, > but just says that they can exist (kind of like the situation for CA > proxying itself). It's silent on the topic of which attributes constitute "session = identification attributes". Q: Session identifications attributes can exist? A: Yes Q: Great! What are they? A: (runs away screaming) That was the subject of LONG discussions in RADEXT. The polite = version is that there was no consensus to make *any* recommendations = here, no matter how small. I'll change the text to: Finally, [RFC5176] is silent on the topic of which attributes constitute "session identification attributes", which makes it impossible for a proxy to determine if a CoA packet matches a particular user session. > The pedant in me takes issue with "impossible" in "impossible to send = CoA > packets to the Visited Network", in Section 3.1 -- I assume that there = are > other contrived and inefficient potential solutions. Yes. > s/one ore more/one or more/ in Section 3.2 Fixed. > In Section 3.3, third paragraph, the references to 2865 and 2866 are = both > Section 4.1; we should probably say both "Section 4.1 of [2865], and = of > Section 4.1 of [2866]. It also seems that a reference to Section 4.1 = (what > a coincidence!) of RFC 5580 might be in order, to note the parallelism > between Operator-NAS-Identifier and Operator-Name. Yes. I'll update it. > In Section 4.2, third paragraph, presumably the non-requirement for > tracking in a database "every individual value" applies only to those > values that are actually issued. (That is, I'm asking to add = "issued," in > "every value of Operator-NAS-Identifier issued, in a database".) Yes. I'll update it. > In Section 4.3.2, do we want to "specifically note" or "call out" = instead > of just "note" that the above requirements apply to future attributes = added > by a proxy (as well as the ones defined here)? (This is something of = a > style question, so it's up to you.) I think it's fine as-is. > Section 5.1, s/xwill/will/ Fixed. > In the last paragraph of Section 5.1, do we need to say that the = recording > is done "if present"? Yes. > Section 5.2, s/disconnecte/disconnected/; s/recieve/receive/; > s/fromt he/from the/ Yes. > Also in Section 5.2, do we want to add "next-hop" when talking about > finding "the CoA server for that realm"? Yes. > And, in the last paragraph, we > say "Any response from the CoA server [...]", but isn't the CoA server > required to send such a response? Yes. But it may be down. :) Alan DeKok. From nobody Mon Jul 30 09:40:23 2018 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CF1130DC8; Mon, 30 Jul 2018 09:40:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: radext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: radext@ietf.org Message-ID: <153296881444.753.17973419684087993027@ietfa.amsl.com> Date: Mon, 30 Jul 2018 09:40:14 -0700 Archived-At: Subject: [radext] I-D Action: draft-ietf-radext-coa-proxy-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 16:40:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions WG of the IETF. Title : Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS) Authors : Alan DeKok Jouni Korhonen Filename : draft-ietf-radext-coa-proxy-05.txt Pages : 16 Date : 2018-07-30 Abstract: RFC 5176 defines Change of Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. Section 3.1 of that document suggests that proxying these messages is possible, but gives no guidance as to how that is done. This specification corrects that omission for scenarios where networks use Realm-based proxying as defined in [RFC7542]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-radext-coa-proxy-05 https://datatracker.ietf.org/doc/html/draft-ietf-radext-coa-proxy-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-coa-proxy-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 30 09:43:41 2018 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9740F130E62 for ; Mon, 30 Jul 2018 09:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJQJt0iE7rED for ; Mon, 30 Jul 2018 09:43:37 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0E9130DC8 for ; Mon, 30 Jul 2018 09:43:37 -0700 (PDT) Received: from [192.168.20.16] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id D4517376; Mon, 30 Jul 2018 16:43:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <153296881444.753.17973419684087993027@ietfa.amsl.com> Date: Mon, 30 Jul 2018 12:43:34 -0400 Cc: Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <04135325-0626-4B1B-A410-6A7078BB5990@deployingradius.com> References: <153296881444.753.17973419684087993027@ietfa.amsl.com> To: radext@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-coa-proxy-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 16:43:40 -0000 This should be the final revision with updates from Benjamin's review. > On Jul 30, 2018, at 12:40 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the RADIUS EXTensions WG of the IETF. >=20 > Title : Dynamic Authorization Proxying in Remote = Authorization Dial-In User Service Protocol (RADIUS) > Authors : Alan DeKok > Jouni Korhonen > Filename : draft-ietf-radext-coa-proxy-05.txt > Pages : 16 > Date : 2018-07-30 >=20 > Abstract: > RFC 5176 defines Change of Authorization (CoA) and Disconnect = Message > (DM) behavior for RADIUS. Section 3.1 of that document suggests = that > proxying these messages is possible, but gives no guidance as to how > that is done. This specification corrects that omission for > scenarios where networks use Realm-based proxying as defined in > [RFC7542]. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-radext-coa-proxy-05 > https://datatracker.ietf.org/doc/html/draft-ietf-radext-coa-proxy-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-coa-proxy-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Mon Jul 30 14:51:36 2018 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2A3130EF3 for ; Mon, 30 Jul 2018 14:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lllaqR87bxab for ; Mon, 30 Jul 2018 14:51:32 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59516130ED9 for ; Mon, 30 Jul 2018 14:51:32 -0700 (PDT) X-AuditID: 1209190e-2e9ff7000000527b-65-5b5f8862552f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 28.69.21115.2688F5B5; Mon, 30 Jul 2018 17:51:31 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w6ULpQu6019371; Mon, 30 Jul 2018 17:51:28 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w6ULpMES006919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jul 2018 17:51:25 -0400 Date: Mon, 30 Jul 2018 16:51:22 -0500 From: Benjamin Kaduk To: Alan DeKok Cc: radext@ietf.org Message-ID: <20180730215122.GM79679@kduck.kaduk.org> References: <153296881444.753.17973419684087993027@ietfa.amsl.com> <04135325-0626-4B1B-A410-6A7078BB5990@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04135325-0626-4B1B-A410-6A7078BB5990@deployingradius.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixG6nopvcER9tcHo/r0XT5yZ2i5ZXM9kc mDxajraweCxZ8pMpgCmKyyYlNSezLLVI3y6BK2PnzFNMBdcEK6Y9Wc/ewHiDt4uRg0NCwERi 5UrdLkYuDiGBxUwSC34cY4RwNjJK3N+6nQnCucokcXr7UZYuRk4OFgFViWMvt7CD2GwCKhIN 3ZeZQWwRAS2JBesXgdUwCwhLbDy1ngnEFhZwkZgwaSZYDS/Qto9HHjCCbBYSqJfomWYCERaU ODnzCVSrlsSNfy+ZQEqYBaQllv/jAAlzCrhLbP1zCaxEVEBZYm/fIfYJjAKzkHTPQtI9C6F7 ASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1jvdzMEr3UlNJNjKAQ5ZTk28E4qcH7EKMAB6MS D6+HVny0EGtiWXFl7iFGSQ4mJVHe//JAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8NjJAOd6U xMqq1KJ8mJQ0B4uSOO+9mvBoIYH0xJLU7NTUgtQimKwMB4eSBG9WO1CjYFFqempFWmZOCUKa iYMTZDgP0HBdkBre4oLE3OLMdIj8KUZdjj/vp05iFmLJy89LlRLnNQIpEgApyijNg5sDSi0S 2ftrXjGKA70lzBsGUsUDTEtwk14BLWECWqIdEguypCQRISXVwNgX8PgQY7yI+YOpYQIfs5yd BNKYDleK6z6c/GaR6X/b0uq2GWz8lp8jrr0SuBFv3zh1w85V98Vs87aHbJ9xJv/fh56/jvPV VydOSNFJuG/0woFN7rro6RvlC/wXuomd+zgp9aGRY8Vxf8k7Hz8/1zN6ufKmUI3lwuQFnA1J hwNmaN++9jxEvluJpTgj0VCLuag4EQBa1L0xCAMAAA== Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-coa-proxy-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 21:51:35 -0000 Thanks (for both the update, and the earlier reply that explained some of the things that my comments were uncertain about)! I'll go ahead and request IETF LC (and expect the gen-art reviewer to spot a couple new typos). -Benjamin On Mon, Jul 30, 2018 at 12:43:34PM -0400, Alan DeKok wrote: > This should be the final revision with updates from Benjamin's review. > > > On Jul 30, 2018, at 12:40 PM, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the RADIUS EXTensions WG of the IETF. > > > > Title : Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS) > > Authors : Alan DeKok > > Jouni Korhonen > > Filename : draft-ietf-radext-coa-proxy-05.txt > > Pages : 16 > > Date : 2018-07-30 > > > > Abstract: > > RFC 5176 defines Change of Authorization (CoA) and Disconnect Message > > (DM) behavior for RADIUS. Section 3.1 of that document suggests that > > proxying these messages is possible, but gives no guidance as to how > > that is done. This specification corrects that omission for > > scenarios where networks use Realm-based proxying as defined in > > [RFC7542]. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-radext-coa-proxy-05 > > https://datatracker.ietf.org/doc/html/draft-ietf-radext-coa-proxy-05 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-coa-proxy-05 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext > From nobody Mon Jul 30 15:00:42 2018 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFC0130F0D; Mon, 30 Jul 2018 15:00:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk CC: radext@ietf.org, stefan.winter@restena.lu, draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org, kaduk@mit.edu, Stefan Winter Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153298803571.7871.5928291867702403220.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2018 15:00:35 -0700 Archived-At: Subject: [radext] Last Call: (Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS)) to Proposed Standard X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 22:00:36 -0000 The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS)' as Proposed Standard 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 2018-08-13. 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 RFC 5176 defines Change of Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. Section 3.1 of that document suggests that proxying these messages is possible, but gives no guidance as to how that is done. This specification corrects that omission for scenarios where networks use Realm-based proxying as defined in [RFC7542]. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) (Informational - IETF stream)