From aland@deployingradius.com Mon Sep 2 08:14:57 2013 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 39A7D11E80E0 for ; Mon, 2 Sep 2013 08:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6Kvb4hbvc-w for ; Mon, 2 Sep 2013 08:14:51 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A15F21F9F70 for ; Mon, 2 Sep 2013 08:14:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 2866922400FB; Mon, 2 Sep 2013 17:13:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x08FtQ-SrvGk; Mon, 2 Sep 2013 17:13:48 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.218.116]) by power.freeradius.org (Postfix) with ESMTPSA id 8A2B0224005C; Mon, 2 Sep 2013 17:13:48 +0200 (CEST) Message-ID: <5224AB2B.7000808@deployingradius.com> Date: Mon, 02 Sep 2013 11:13:47 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 02 Sep 2013 15:14:57 -0000 Peter Deacon wrote: > Proposed 'T' bit in extended long attributes means existing systems > supporting extended attributes may require enhancement to pass needed > data. Despite 'SHOULD' language from RFC6929 I do not believe it > reasonable expectation proxy systems able to understand an attribute > known to be broke would elect to forward such an attribute anyway. The draft authors had a conference call this morning about this, and other issues. RFC 6929 Section 5.2 says: This practice is NOT RECOMMENDED. Proxy servers SHOULD forward attributes, even attributes that they do not understand or that are not in a local dictionary. When forwarded, these attributes SHOULD be sent verbatim, with no modifications or changes. This requirement includes "invalid attributes", as there may be some other system in the network that understands them. I believe that this text directly addresses the "T" bit, and the possibility of fragmenting attributes across multiple packets. You say that it's not reasonable to expect a proxy to forward such an attribute. You haven't given any reason for that opinion. Until we have such discussion, we have real-world data from Eduroam, among other examples. There have been real-world issues with proxies receiving attributes they don't understand, or think are malformed. Some proxies would then discard the packets or offending attributes. This misbehavior caused real-world deployment problems. The solution was to ensure that all proxies forwarded these attributes, even if they didn't understand them. In conclusion, I believe we're safe in adding the "T" bit in the fragmentation draft. Implementations compliant with 6929 will ignore the "T" bit, but SHOULD still forward the attributes they believe are malformed (when the T bit is set) If you're saying that your implementation discards these attributes, I would suggest that your implementation is incompatible with new standards, and existing deployments. Alan DeKok. From peterd@iea-software.com Mon Sep 2 10:43:00 2013 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 B5E6611E8133 for ; Mon, 2 Sep 2013 10:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3V3dGTqIQf2Z for ; Mon, 2 Sep 2013 10:42:55 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 81A5221F9FF1 for ; Mon, 2 Sep 2013 10:42:55 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 2 Sep 2013 10:42:54 -0700 Date: Mon, 2 Sep 2013 10:42:53 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5224AB2B.7000808@deployingradius.com> Message-ID: References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <5224AB2B.7000808@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 02 Sep 2013 17:43:00 -0000 On Mon, 2 Sep 2013, Alan DeKok wrote: >> Proposed 'T' bit in extended long attributes means existing systems >> supporting extended attributes may require enhancement to pass needed >> data. Despite 'SHOULD' language from RFC6929 I do not believe it >> reasonable expectation proxy systems able to understand an attribute >> known to be broke would elect to forward such an attribute anyway. > The draft authors had a conference call this morning about this, and > other issues. > RFC 6929 Section 5.2 says: > This practice is NOT RECOMMENDED. Proxy servers SHOULD forward > attributes, even attributes that they do not understand or that are > not in a local dictionary. When forwarded, these attributes SHOULD > be sent verbatim, with no modifications or changes. This requirement > includes "invalid attributes", as there may be some other system in > the network that understands them. > I believe that this text directly addresses the "T" bit, and the > possibility of fragmenting attributes across multiple packets. You say > that it's not reasonable to expect a proxy to forward such an attribute. > You haven't given any reason for that opinion. Yep, it sure is what I was referring to by "'SHOULD' language". Seems like a fairly common and obvious security 101 precaution in our (my) space you just don't forward what you know to be broke especially where it involves authentication/authorization parameters. I see no reason at all to allow such behavior to take place. > Until we have such discussion, we have real-world data from Eduroam, > among other examples. There have been real-world issues with proxies > receiving attributes they don't understand, or think are malformed. > Some proxies would then discard the packets or offending attributes. > This misbehavior caused real-world deployment problems. The solution > was to ensure that all proxies forwarded these attributes, even if they > didn't understand them. There are two issues which seem to be embedded in the above. 1. Forwarding of attributes you don't understand. 2. Incursions into standard space by vendor "A" and others. Regarding #1 My opinion there certainly is value in administrative configuration allowing forwarding of unknown attributes. I encourage all vendors to provide such an option to their customers. Whether this is done or not seems to be orthogonal to the issue of rejecting a known attribute you know to be malformed. Regarding #2 As far as I'm concerned this is ancient history, has been for years and irrelevant in 2013. Capitulating to an environment where nobody can be sure what an attribute even means is unacceptable. Some attribute dictionaries have long memories and are quite easily changed. As with #1 the underlying issue seems to be orthogonal. With this issue the conflict is invoked by systems not agreeing on attribute "type". In case of fragment draft "type" is not in question. The problem here a type's format has been changed retroactively in an incompatible manner. I do not support use of above as "cover" to justify incompatible retroactive changes. My recommendation going forward is to find an alternative option which does not depend on incompatible M flag behavior. One option in the definition of any long attributes to convey eduroam/SAML data specify how partial content should be handled and allocate new flags to effect inter-packet continuation without changing existing behavior. regards, Peter From aland@deployingradius.com Mon Sep 2 13:23:42 2013 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 1397121F9D0D for ; Mon, 2 Sep 2013 13:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wGqfpXmkg1N for ; Mon, 2 Sep 2013 13:23:36 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 22C7821F9CE2 for ; Mon, 2 Sep 2013 13:23:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 359FC22400FB; Mon, 2 Sep 2013 22:23:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wanm0LxYWszw; Mon, 2 Sep 2013 22:23:26 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.218.116]) by power.freeradius.org (Postfix) with ESMTPSA id 75F0122400EF; Mon, 2 Sep 2013 22:23:26 +0200 (CEST) Message-ID: <5224F3BE.4070902@deployingradius.com> Date: Mon, 02 Sep 2013 16:23:26 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <5224AB2B.7000808@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 02 Sep 2013 20:23:42 -0000 Peter Deacon wrote: > Seems like a fairly common and obvious security 101 precaution in our > (my) space you just don't forward what you know to be broke especially > where it involves authentication/authorization parameters. I see no > reason at all to allow such behavior to take place. As I've said before, that attitude could prevent *any* new functionality from being deployed. Some proxy implementations discarded any attributes which were not in the local dictionary. This idiocy isn't forbidden by the previous RFCs, but is finally discouraged by 6929. It prevents *any* changes to RADIUS, which is madness. > My opinion there certainly is value in administrative configuration > allowing forwarding of unknown attributes. I encourage all vendors to > provide such an option to their customers. > > Whether this is done or not seems to be orthogonal to the issue of > rejecting a known attribute you know to be malformed. No. A known attribute which uses fields that had previously been marked "reserved". And even if it is malformed, there are ways to deal with it. > Regarding #2 > > As far as I'm concerned this is ancient history, has been for years and > irrelevant in 2013. No. Vendors still ship equipment which poaches on the standard space. Deployments still rely on those attributes. Eduroam was running into issues with these attributes in the recent past. With widely-used, in-support commercial RADIUS servers. > As with #1 the underlying issue seems to be orthogonal. With this issue > the conflict is invoked by systems not agreeing on attribute "type". In > case of fragment draft "type" is not in question. The problem here a > type's format has been changed retroactively in an incompatible manner. I disagree, for reasons I've stated. > My recommendation going forward is to find an alternative option which > does not depend on incompatible M flag behavior. > > One option in the definition of any long attributes to convey > eduroam/SAML data specify how partial content should be handled and > allocate new flags to effect inter-packet continuation without changing > existing behavior. Where would those "new flags" exist? In a new attribute format? Creating a brand-new incompatible standard isn't a solution to another (allegedly) incompatible standard. For me, it's a simple principle. Proxies have NO BUSINESS mucking around with attributes they don't understand. If the RADIUS packet is well formed, the attributes (understood or not) should be sent onwards. Alan DeKok. From peterd@iea-software.com Mon Sep 2 18:33:44 2013 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 E8C4A21F9E80 for ; Mon, 2 Sep 2013 18:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh5snm+hOs3M for ; Mon, 2 Sep 2013 18:33:39 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id BE60E21F9E7E for ; Mon, 2 Sep 2013 18:33:39 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 2 Sep 2013 18:33:38 -0700 Date: Mon, 2 Sep 2013 18:33:38 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5224F3BE.4070902@deployingradius.com> Message-ID: References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <5224AB2B.7000808@deployingradius.com> <5224F3BE.4070902@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 01:33:45 -0000 On Mon, 2 Sep 2013, Alan DeKok wrote: > Some proxy implementations discarded any attributes which were not in > the local dictionary. This idiocy isn't forbidden by the previous RFCs, > but is finally discouraged by 6929. It prevents *any* changes to > RADIUS, which is madness. >> My opinion there certainly is value in administrative configuration >> allowing forwarding of unknown attributes. I encourage all vendors to >> provide such an option to their customers. >> Whether this is done or not seems to be orthogonal to the issue of >> rejecting a known attribute you know to be malformed. > No. A known attribute which uses fields that had previously been > marked "reserved". And even if it is malformed, there are ways to deal > with it. To be clear the issue is not allocation of reserved fields it is M bit set where RFC6929 requires it not be. > No. Vendors still ship equipment which poaches on the standard space. > Deployments still rely on those attributes. Eduroam was running into > issues with these attributes in the recent past. With widely-used, > in-support commercial RADIUS servers. Which vendors still use 241-246? >> One option in the definition of any long attributes to convey >> eduroam/SAML data specify how partial content should be handled and >> allocate new flags to effect inter-packet continuation without changing >> existing behavior. > Where would those "new flags" exist? In a new attribute format? Allocation of reserved bits from RFC6929. > Creating a brand-new incompatible standard isn't a solution to another > (allegedly) incompatible standard. > For me, it's a simple principle. Proxies have NO BUSINESS mucking > around with attributes they don't understand. If the RADIUS packet is > well formed, the attributes (understood or not) should be sent onwards. In this case lack of knowledge is NOT the problem. The problem is proxies KNOWING something is WRONG and being expected to look the other way and forward the information on anyway. regards, Peter From aland@deployingradius.com Mon Sep 2 19:19:02 2013 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 8ACBF21F9EE5 for ; Mon, 2 Sep 2013 19:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf6Giz-xXnbz for ; Mon, 2 Sep 2013 19:18:56 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2DD121F9C83 for ; Mon, 2 Sep 2013 19:18:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 80C6622400FB; Tue, 3 Sep 2013 04:18:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c09cEkR3Qo09; Tue, 3 Sep 2013 04:18:51 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.218.116]) by power.freeradius.org (Postfix) with ESMTPSA id 2258822400EF; Tue, 3 Sep 2013 04:18:51 +0200 (CEST) Message-ID: <52254709.5030208@deployingradius.com> Date: Mon, 02 Sep 2013 22:18:49 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <5224AB2B.7000808@deployingradius.com> <5224F3BE.4070902@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 02:19:02 -0000 Peter Deacon wrote: > To be clear the issue is not allocation of reserved fields it is M bit > set where RFC6929 requires it not be. OK. > Which vendors still use 241-246? Large ones. The functionality is disabled by default, but is still in many products. I deal with this all of the time. > Allocation of reserved bits from RFC6929. Which suggests the question: how do we ever extend 6929 to use the reserved bits? > In this case lack of knowledge is NOT the problem. The problem is > proxies KNOWING something is WRONG and being expected to look the other > way and forward the information on anyway. Yes. That's EXACTLY what proxies should be doing. Anything else causes a disaster. I explained why I have my opinion, using real-world examples. Your counter-argument is to re-state that this is a problem. You don't dispute my examples, and you don't offer a counter-argument to them. I can only conclude that you're disagreeing because of some un-named fear. Alan DeKok. From diego@tid.es Tue Sep 3 09:09:10 2013 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 E424821F9D31 for ; Tue, 3 Sep 2013 09:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.525 X-Spam-Level: X-Spam-Status: No, score=-4.525 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zAqczP73hwi for ; Tue, 3 Sep 2013 09:09:06 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id E4A8921E814E for ; Tue, 3 Sep 2013 09:09:05 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MSK00M0E4V2BU@tid.hi.inet> for radext@ietf.org; Tue, 03 Sep 2013 18:09:02 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id EC.47.28420.E9906225; Tue, 03 Sep 2013 18:09:02 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MSK00M024V1BU@tid.hi.inet> for radext@ietf.org; Tue, 03 Sep 2013 18:09:02 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Tue, 03 Sep 2013 18:09:01 +0200 Date: Tue, 03 Sep 2013 16:09:00 +0000 From: "Diego R. Lopez" In-reply-to: <52254709.5030208@deployingradius.com> X-Originating-IP: [10.95.64.115] To: Alan DeKok Message-id: <74B487C3-6385-421F-A1FD-6C75EB7A9C29@tid.es> Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 Thread-index: AQHOqEyuzW56czpYmk+yscMJP0W6O5m0DawA X-AuditID: 0a5f4e69-b7fe58e000006f04-0e-5226099e8334 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42Lhivcz1J3HqRZk8HWhukXLq5lsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK2N5cUXBPuOL5i6PsDYxzhLsYOTkkBEwkTn3qYoGwxSQu3FvP 1sXIxSEksJ1R4lXHcSYI5xejxI5JT9khnJmMEvsnz2cFaWERUJV4deoTWDsbkP2o+Tc7iC0s ECLxvm8yI4jNKWAs0X1uAdQKBYk/5x6D2SICWhIL1i8Cs5kF/CWWrmhnA7F5BSwlTr+YwAwR N5N4fPgGVFxQ4sfke0D1HEBxdYkpU3IhSsQlmltvQo1RlJi2qAFsLaOArMS7+RBnigiESjR9 n8MM0ioiYCSxr8Uf4hoBiSV7zjND2KISLx//Y4V4cR+TRPPRZSwTGCVmIbliFpIrZiFcMQvJ FbOQXLGAkXUVo1hxUlFmekZJbmJmTrqBkV5Gpl5mXmrJJkZIzGXuYFy+U+UQowAHoxIPL8Mj 1SAh1sSy4srcQ4wSHMxKIrxbWNWChHhTEiurUovy44tKc1KLDzEycXBKNTCmbLu77bWT8Ryl rZ+u5XO3nViy55t1VemH2+Fr75bMmrTTLe0fVxLHxoMPJ3AGz1jfo8WuUP3wfotMhv/qLxPe pityLeTI8DzzPGyC0kVhq1kqpR9bJpyP2jq92GTt1CObj9gd8Y04dUrOuCLP9MHcO3trPFQ7 Zvk9nxPc0iX8ZyPbs0uLv66wVmIpzkg01GIuKk4EAEldK/WXAgAA References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <5224AB2B.7000808@deployingradius.com> <5224F3BE.4070902@deployingradius.com> <52254709.5030208@deployingradius.com> Cc: "radext@ietf.org" , Peter Deacon Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 16:09:11 -0000 SGksDQoNCk9uIDMgU2VwIDIwMTMsIGF0IDA0OjE4ICwgQWxhbiBEZUtvayB3cm90ZToNCj4gUGV0 ZXIgRGVhY29uIHdyb3RlOg0KPj4gSW4gdGhpcyBjYXNlIGxhY2sgb2Yga25vd2xlZGdlIGlzIE5P VCB0aGUgcHJvYmxlbS4gIFRoZSBwcm9ibGVtIGlzDQo+PiBwcm94aWVzIEtOT1dJTkcgc29tZXRo aW5nIGlzIFdST05HIGFuZCBiZWluZyBleHBlY3RlZCB0byBsb29rIHRoZSBvdGhlcg0KPj4gd2F5 IGFuZCBmb3J3YXJkIHRoZSBpbmZvcm1hdGlvbiBvbiBhbnl3YXkuDQo+DQo+ICBZZXMuICBUaGF0 J3MgRVhBQ1RMWSB3aGF0IHByb3hpZXMgc2hvdWxkIGJlIGRvaW5nLiAgQW55dGhpbmcgZWxzZQ0K PiBjYXVzZXMgYSBkaXNhc3Rlci4NCj4NCj4gIEkgZXhwbGFpbmVkIHdoeSBJIGhhdmUgbXkgb3Bp bmlvbiwgdXNpbmcgcmVhbC13b3JsZCBleGFtcGxlcy4gIFlvdXINCj4gY291bnRlci1hcmd1bWVu dCBpcyB0byByZS1zdGF0ZSB0aGF0IHRoaXMgaXMgYSBwcm9ibGVtLg0KPg0KPiAgWW91IGRvbid0 IGRpc3B1dGUgbXkgZXhhbXBsZXMsIGFuZCB5b3UgZG9uJ3Qgb2ZmZXIgYSBjb3VudGVyLWFyZ3Vt ZW50DQo+IHRvIHRoZW0uICBJIGNhbiBvbmx5IGNvbmNsdWRlIHRoYXQgeW91J3JlIGRpc2FncmVl aW5nIGJlY2F1c2Ugb2Ygc29tZQ0KPiB1bi1uYW1lZCBmZWFyLg0KDQoNCkFzIEkgc2VlIGl0LCB0 aGVyZSBpcyBhIGNsZWFyIHJ1bGUgZm9yIHByb3h5IGJlaGF2aW9yIHdpdGggcmVzcGVjdCB0byB0 aGlzOiBQcm94aWVzIGhhdmUgdG8gYmVoYXZlIGluIHRoZSBtb3N0IHRyYW5zcGFyZW50IHBvc3Np YmxlIHdheSBiZWNhdXNlIHRoZXkgYXJlIHNpbXBseSByZWxheXMgZm9yIHRoZSBjb21tdW5pY2F0 aW9uLiBWYWxpZGF0aW9ucyAoZm9yIHNlY3VyaXR5LCBzZW1hbnRpY3Mgb3Igd2hhdGV2ZXIgZWxz ZSkgc2hvdWxkIG9jY3VyIG9ubHkgRTJFLiBJZiB5b3Ugd2FudCB0byBoYXZlIGEgbWlkZGxlYm94 IHRoYXQgYnJlYWtzIEUyRSB2YWxpZGF0aW9uIGZvciB3aGF0ZXZlciB0aGUgcmVhc29uIChhcyBt dWNoIGxlZ2l0aW1hdGUgYXMgaXQgY2FuIGJlKSBkb24ndCBjbGFpbSBpdCB0byBiZSBhIHByb3h5 Lg0KDQpJbiBicmllZjogSG9wLWJ5LWhvcCBzZWN1cml0eSBNVVNUIGJlIGNoZWNrZWQgYXQgZWFj aCBwcm94eSwgb2YgY291cnNlLiBCdXQgRTJFIHNlY3VyaXR5IE1VU1QgTk9UIGJlIGNoZWNrZWQg YXQgYSBwcm94eS4NCg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywg RG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0 dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvQHRpZC5lcw0K VGVsOiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUg YSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBl bnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNp dHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBm b3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBi YXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lO QVMvZGlzY2xhaW1lci5hc3B4DQo= From peterd@iea-software.com Tue Sep 3 10:37:54 2013 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 C808A11E80E7 for ; Tue, 3 Sep 2013 10:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRCUYoK1fjSn for ; Tue, 3 Sep 2013 10:37:48 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id D271B11E8100 for ; Tue, 3 Sep 2013 10:37:09 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 3 Sep 2013 10:37:07 -0700 Date: Tue, 3 Sep 2013 10:37:07 -0700 (Pacific Daylight Time) From: Peter Deacon To: "Diego R. Lopez" In-Reply-To: <74B487C3-6385-421F-A1FD-6C75EB7A9C29@tid.es> Message-ID: References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <5224AB2B.7000808@deployingradius.com> <5224F3BE.4070902@deployingradius.com> <52254709.5030208@deployingradius.com> <74B487C3-6385-421F-A1FD-6C75EB7A9C29@tid.es> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" , Alan DeKok Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 17:37:54 -0000 On Tue, 3 Sep 2013, Diego R. Lopez wrote: > As I see it, there is a clear rule for proxy behavior with respect to > this: Proxies have to behave in the most transparent possible way > because they are simply relays for the communication. Validations (for > security, semantics or whatever else) should occur only E2E. If you want While I appreciate many here are working on behalf of a specific network assumptions made above are not universal. For example consider a roaming network enforcing data filtering rules for all participants. It may check authorization parameters and inject additional rules to meet networks policy objectives if home authentication server has neglected to enforce agreed upon policy. > to have a middlebox that breaks E2E validation for whatever the reason > (as much legitimate as it can be) don't claim it to be a proxy. In this specific case the problem is 'M' bit in long extended type is set where RFC6929 says it ought not to be. As any logical attribute can be conveyed the purpose "E2E" or otherwise does not seem to be knowable in advance. > In brief: Hop-by-hop security MUST be checked at each proxy, of course. > But E2E security MUST NOT be checked at a proxy. As stipulated when I originally responded to call for adoption my objections to this draft only apply when scope is not narrowed to where authors intend to use it. (e.g. Eduroam) I don't support the above sentence with HOP/E2E/MUST/MUST NOT language in the general context although it may seem perfectly reasonable in the context of your network. regards, Peter From aland@deployingradius.com Tue Sep 3 13:48:08 2013 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 223F021E8064 for ; Tue, 3 Sep 2013 13:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEazqrrqrvLe for ; Tue, 3 Sep 2013 13:48:02 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E40711E8130 for ; Tue, 3 Sep 2013 13:48:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 961A82240133; Tue, 3 Sep 2013 22:47:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9knoNhqjuzs; Tue, 3 Sep 2013 22:47:02 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.218.116]) by power.freeradius.org (Postfix) with ESMTPSA id 3F9EA224003F; Tue, 3 Sep 2013 22:47:02 +0200 (CEST) Message-ID: <52264AC6.3080702@deployingradius.com> Date: Tue, 03 Sep 2013 16:47:02 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <5224AB2B.7000808@deployingradius.com> <5224F3BE.4070902@deployingradius.com> <52254709.5030208@deployingradius.com> <74B487C3-6385-421F-A1FD-6C75EB7A9C29@tid.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "Diego R. Lopez" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 20:48:08 -0000 Peter Deacon wrote: > For example consider a roaming network enforcing data filtering rules > for all participants. It may check authorization parameters and inject > additional rules to meet networks policy objectives if home > authentication server has neglected to enforce agreed upon policy. i.e. that proxy is largely *terminating* the authorization parameters, and injecting new ones. I used to work at a roaming company where we did exactly that, so I'm aware of the use-case. I think the fragmentation draft needs to support the use-case, too. > In this specific case the problem is 'M' bit in long extended type is > set where RFC6929 says it ought not to be. As any logical attribute can > be conveyed the purpose "E2E" or otherwise does not seem to be knowable > in advance. The intention of the client is to convey the authorization data to the home server. That seems a fairly clear E2E purpose to me. > As stipulated when I originally responded to call for adoption my > objections to this draft only apply when scope is not narrowed to where > authors intend to use it. (e.g. Eduroam) The draft can be useful outside of that context. My suggestion allows it to be used in a roaming context like you suggest. I see the objections as being largely artificial in nature. If a client needs to use the draft inside of a roaming consortium, it can: a) send the data, and proxies won't filter / modify it b) ask the proxies to upgrade to support the draft, at which point they can filter / modify the fragmented data. Both options are workable. Alan DeKok. From hartmans@painless-security.com Tue Sep 3 15:48:18 2013 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 4098F21F9E5E for ; Tue, 3 Sep 2013 15:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o83hrFiJQW4w for ; Tue, 3 Sep 2013 15:48:12 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5D90521F9CC2 for ; Tue, 3 Sep 2013 15:48:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 1558C2031B; Tue, 3 Sep 2013 18:48:08 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lk4cnshV530; Tue, 3 Sep 2013 18:48:07 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 3 Sep 2013 18:48:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C444087FAC; Tue, 3 Sep 2013 18:48:06 -0400 (EDT) From: Sam Hartman To: Jouni Korhonen References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> Date: Tue, 03 Sep 2013 18:48:06 -0400 In-Reply-To: (Jouni Korhonen's message of "Mon, 26 Aug 2013 10:35:56 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , radext-chairs@tools.ietf.org, "draft-perez-radext-radius-fragmentation@tools.ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 22:48:18 -0000 >>>>> "Jouni" == Jouni Korhonen writes: Jouni> Folks, Jouni> We will take draft-perez-radext-radius-fragmentation-06 as Jouni> the _basis_ for the WG solution Hi. I'd be happy if you reword that sentence as "_a_ _basis_ for _a_ WG solution." I think there was significant support for the idea that this draft alone is insufficient and that we want to revisit the RADIUS message size over TCP. I do not believe the discussion supports the idea that this draft will be a singular solution. So, I'd ask the chairs to clarify. --Sam From aland@deployingradius.com Wed Sep 4 05:10:43 2013 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 666DC11E81A5 for ; Wed, 4 Sep 2013 05:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQbyd7ibShEl for ; Wed, 4 Sep 2013 05:10:37 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7175211E8128 for ; Wed, 4 Sep 2013 05:10:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id E4C3A224010D; Wed, 4 Sep 2013 14:10:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0pcbqeVerst; Wed, 4 Sep 2013 14:10:34 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.218.116]) by power.freeradius.org (Postfix) with ESMTPSA id 0A3EF2240051; Wed, 4 Sep 2013 14:10:33 +0200 (CEST) Message-ID: <5227233B.100@deployingradius.com> Date: Wed, 04 Sep 2013 08:10:35 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jouni Korhonen , "draft-perez-radext-radius-fragmentation@tools.ietf.org" , radext-chairs@tools.ietf.org, "radext@ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 12:10:43 -0000 Sam Hartman wrote: > I think there was significant support for the idea that this draft alone > is insufficient and that we want to revisit the RADIUS message size over > TCP. I agree. > I do not believe the discussion supports the idea that this draft will > be a singular solution. The discussion at the last IETF showed this. There is wide-spread support for large packets over TCP. From what I can see, the only issue with large packets is negotiation. How does each end know that the other supports large packets? Once that problem is solve, the rest of the draft is simple. I don't think that there are many other side effects of allowing large packets. Alan DeKok.