From aland@deployingradius.com Mon Oct 1 01:34:25 2012 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 5876F21F860E for ; Mon, 1 Oct 2012 01:34:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6Q3YV3nSZ9K for ; Mon, 1 Oct 2012 01:34:24 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3490B21F860B for ; Mon, 1 Oct 2012 01:34:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 30BC02240D01; Mon, 1 Oct 2012 10:33:16 +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 lnBtYqWtuDsc; Mon, 1 Oct 2012 10:33:14 +0200 (CEST) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by power.freeradius.org (Postfix) with ESMTPSA id 234C02240797; Mon, 1 Oct 2012 10:33:14 +0200 (CEST) Message-ID: <5069554F.2000701@deployingradius.com> Date: Mon, 01 Oct 2012 10:33:19 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <5067EE7A.2090201@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, jouni korhonen , Peter Deacon Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 08:34:25 -0000 Sam Hartman wrote: > As I understand it, existing RFCs allow a system to reorder attributes > of the same type. Re-ordering is expressly forbidden by RFC 2865, Section 2.3, page 10: ... The forwarding server MUST NOT change the order of any attributes of the same type, including Proxy-State. > So, you send an extensions packet to a non-extensions proxy. That proxy > happens to reorder the packets in a manner that some attacker > understands but that the sending system and final server do not. This > is likely to lead to corruption even without an attacker. IN the > presence of an attacker, who controlled inputs that got packaged up in > the fragmented attributes, the attacker may be able to inject a > fragmented attribute not present in the original packet of the > attacker's choosing. That's possible. Using a "start fragments" bit would alleviate this. Packets which have the bit set (or unset) incorrectly would be silently discarded. > I think that if we don't choose to address this issue, it needs to be > documented in the security considerations section. I think whether it's > OK to not address the issue depends on what's out there in the wild. I'm > happy to defer to Alan and others on that. I'd be OK with adding a "start fragments" bit, and adding a sentence or two in the Security Considerations section discussing why the bit was added. Alan DeKok. From hartmans@painless-security.com Mon Oct 1 01:52:22 2012 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 0F1FD21F85EF for ; Mon, 1 Oct 2012 01:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.398 X-Spam-Level: **** X-Spam-Status: No, score=4.398 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYHfpzAT1CdV for ; Mon, 1 Oct 2012 01:52:21 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 92AC121F85C7 for ; Mon, 1 Oct 2012 01:52:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D21FE20118; Mon, 1 Oct 2012 04:16:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A74EC414A; Mon, 1 Oct 2012 04:16:53 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <5067EE7A.2090201@deployingradius.com> Date: Mon, 01 Oct 2012 04:16:53 -0400 In-Reply-To: <5067EE7A.2090201@deployingradius.com> (Alan DeKok's message of "Sun, 30 Sep 2012 09:02:18 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, jouni korhonen , Peter Deacon Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 08:52:22 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> I don't understand that. Existing systems which are RFC Alan> compliant and *not* supporting extensions won't be affected by Alan> them. The extensions attributes use previously undefined Alan> numbers. RFC compliant systems don't touch unassigned Alan> attributes. I think Alan understands this at this point, but for the rest of the WG, here's what I think the argument is. As I understand it, existing RFCs allow a system to reorder attributes of the same type. That is, a proxy could reorder two type 26 (VSA) attributes or could reorder two of the new fragmentable attributes. An extensions compatible proxy wouldn't do that because the sub-type distinguishes the attributes. So, you send an extensions packet to a non-extensions proxy. That proxy happens to reorder the packets in a manner that some attacker understands but that the sending system and final server do not. This is likely to lead to corruption even without an attacker. IN the presence of an attacker, who controlled inputs that got packaged up in the fragmented attributes, the attacker may be able to inject a fragmented attribute not present in the original packet of the attacker's choosing. I think that if we don't choose to address this issue, it needs to be documented in the security considerations section. I think whether it's OK to not address the issue depends on what's out there in the wild. I'm happy to defer to Alan and others on that. --Sam From stefan.winter@restena.lu Mon Oct 1 02:45:56 2012 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 0F9F321F857E for ; Mon, 1 Oct 2012 02:45:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9Sv8iYMJ4EN for ; Mon, 1 Oct 2012 02:45:55 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C60AD21F8555 for ; Mon, 1 Oct 2012 02:45:52 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 1E0A51058B for ; Mon, 1 Oct 2012 11:45:49 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e] (unknown [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e]) by smtprelay.restena.lu (Postfix) with ESMTPS id 0CAB110589 for ; Mon, 1 Oct 2012 11:45:49 +0200 (CEST) Message-ID: <50696649.5050001@restena.lu> Date: Mon, 01 Oct 2012 11:45:45 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: radext@ietf.org References: <5067EE7A.2090201@deployingradius.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE21260991D05B38C35AA935F" X-Virus-Scanned: ClamAV Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 09:45:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE21260991D05B38C35AA935F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > So, you send an extensions packet to a non-extensions proxy. That prox= y > happens to reorder the packets in a manner that some attacker > understands but that the sending system and final server do not. This > is likely to lead to corruption even without an attacker. IN the > presence of an attacker, who controlled inputs that got packaged up in > the fragmented attributes, the attacker may be able to inject a > fragmented attribute not present in the original packet of the > attacker's choosing. If the RADIUS proxy itself is the malicious entity, it can inject or remove any attribute it so likes; whether it's extended attribs or not. If the attacker is an intermediate IP node, any manipulations would change the Message-Authenticator attribute, right? I feel like I'm missing something... could someone enlighten me? Greetings, Stefan Winter > I think that if we don't choose to address this issue, it needs to be > documented in the security considerations section. I think whether it'= s > OK to not address the issue depends on what's out there in the wild. I'= m > happy to defer to Alan and others on that. >=20 > --Sam > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigE21260991D05B38C35AA935F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBpZkwACgkQ+jm90f8eFWYEQQCdG0N226ABwzL/OuRfh4sLtHvF jZIAnRJaXvEvNs3uWIojv7uiiqWLUgHA =PQCV -----END PGP SIGNATURE----- --------------enigE21260991D05B38C35AA935F-- From aland@deployingradius.com Mon Oct 1 02:56:32 2012 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 566DC21F860E for ; Mon, 1 Oct 2012 02:56:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXDiSZWKFHvf for ; Mon, 1 Oct 2012 02:56:31 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9D9421F8608 for ; Mon, 1 Oct 2012 02:56:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8141F2240D01; Mon, 1 Oct 2012 11:55:28 +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 vqXtL-htDW3r; Mon, 1 Oct 2012 11:55:28 +0200 (CEST) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by power.freeradius.org (Postfix) with ESMTPSA id 15D322240797; Mon, 1 Oct 2012 11:55:28 +0200 (CEST) Message-ID: <50696897.9000600@deployingradius.com> Date: Mon, 01 Oct 2012 11:55:35 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> In-Reply-To: <50696649.5050001@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 09:56:32 -0000 Stefan Winter wrote: > If the RADIUS proxy itself is the malicious entity, it can inject or > remove any attribute it so likes; whether it's extended attribs or not. The issue (I think) is more broken proxies. e.g. proxies as seen in Eduroam, which have self-allocated "unused" attributes. They expect the self-allocated attributes to be in a particular form. They do bad things when they see IETF versions of those attributes. My $0.02 is that detecting this is probably a good idea. Catching mangled fragments is nice. Preventing mangled fragments from causing decode errors is nice. But... in general, proxies mangling attributes they don't understand is stupid. People running those proxies should upgrade to RFC compliant RADIUS servers. e.g. For years the Merit RADIUS server *explicitly* violated the RFCs. Any Proxy-State was treated as an ASCII version of an 8-bit number, such as "42". Packets *not* meeting that criteria were mishandled. This was an issue for a few years on mailing lists I'm on. The solution was always simple: Upgrade to a real RADIUS server. People did. Alan DeKok. From stefan.winter@restena.lu Mon Oct 1 04:40:26 2012 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 6145B21F85B1 for ; Mon, 1 Oct 2012 04:40:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vakYTAAyau+r for ; Mon, 1 Oct 2012 04:40:25 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id B767421F859F for ; Mon, 1 Oct 2012 04:40:24 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 785FC1058B for ; Mon, 1 Oct 2012 13:40:23 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e] (unknown [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e]) by smtprelay.restena.lu (Postfix) with ESMTPS id 62CEC10581 for ; Mon, 1 Oct 2012 13:40:23 +0200 (CEST) Message-ID: <50698127.9040705@restena.lu> Date: Mon, 01 Oct 2012 13:40:23 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: radext@ietf.org References: <5066FE87.6040309@cisco.com> In-Reply-To: <5066FE87.6040309@cisco.com> X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCEE9FA6798D5CA61E8DA77E6" X-Virus-Scanned: ClamAV Subject: Re: [radext] new charter proposal 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, 01 Oct 2012 11:40:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCEE9FA6798D5CA61E8DA77E6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Since we also discussed this new charter during the IETF meeting, I'll > take the lack of replies as agreement. >=20 > However, I have a concern regarding the RADIUS Accounting Extensions fo= r > Traffic Statistics, for two reasons: > 1. there are two competing proposals, tactical approach vs. flexible > approach, as mentioned in the meeting minutes. And there is ongoing > discussion on the mailing regarding the direction to take. If I recall the meeting correctly (remote participation only), I believe there was an extensive discussion and a show of hands which direction to take. I heard after the meeting that the result was 4:1 in favour of a flexivle approach. That show of hands was to be confirmed on the list, but IIRC, this hasn't happened yet. I'd suggest a corresponding poll on the list, and take the result of that as the basis for the new charter. > 2. If we go for the flexible approach, where do we stop in terms of > flexibility? > Should the URN in WInter's draft contain: then ipv4 versus ipv6, then > all the DSCP values, then the next hop, then AS-path ... All of which > To finally end up with the IPFIX flexibility, i.e. a template based > mechanism, based on any selection of all IPFIX IANA IEs > > So I would like the WG to agree on the problem statement first. I believe that once the principle direction "flexible vs. one-purpose" is settle, the *details* of how that flexibility should look like could be part of the normal WG work and doesn't have to explicitly called out in the charter. Greetings, Stefan Winter >=20 > Since both the NAI and the fragmentation work is agreed upon, we could > proceed with the new charter, modulo the "RADIUS Accounting Extensions > for Traffic Statistics" >=20 > Regards, Benoit. >=20 >> Description of Working Group >> >> The RADIUS Extensions Working Group will focus on extensions to the RA= DIUS protocol required to expand and enrich the standard attribute space= , address cryptographic algorithm agility, use of new secure transports = and clarify its usage and definition. >> >> In order to maintain interoperation of heterogeneous RADIUS/Diameter d= eployments, all RADEXT WG work items except those that just define new at= tributes MUST contain a Diameter compatibility section, outlining how int= eroperability with Diameter will be maintained. >> >> Furthermore, to ensure backward compatibility with existing RADIUS im= plementations, as well as compatibility between RADIUS and Diameter, the = following restrictions are imposed on extensions considered by the RADEXT= WG: >> >> - All documents produced MUST specify means of interoperation with leg= acy RADIUS and, if possible, be backward compatible with existing RADIUS= RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, = 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be com= patible with RFC 3539. >> >> Work Items >> The immediate goals of the RADEXT working group are to address the fol= lowing issues: >> >> - RADIUS attribute space extension. The standard RADIUS attribute spac= e is currently being depleted. This document will provide additional stan= dard attribute space, while maintaining backward compatibility with exist= ing attributes. >> >> - IEEE 802 attributes. New attributes have been proposed to support IE= EE 802 standards for wired and wireless LANs. This work item will support= authentication, authorization and accounting attributes needed by IEEE 8= 02 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. >> >> - New RADIUS transports. A reliable transport profile for RADIUS will = be developed, as well as specifications for Secure transports, including = TCP/TLS (RADSEC) and UDP/DTLS. >> >> - Update and clarification of Network Access Identifiers (RFC4282).Thi= s work item will correct and clarify issues present with RFC4282 in two p= hases. In first phase, RFC4282bis will be issued to eliminate fundamenta= l incompatibilities with RADIUS around character encoding and NAI modific= ations by proxies. In second phase, a fresh review of NAI internationali= zation requirements and behavior will be undertaken with a clear goal of = maintaining compatibility with RADIUS. >> >> - RADIUS Accounting Extensions for Traffic Statistics. This work item = will specify RADIUS accounting attributes for differentiated accounting p= olices and traffic recording. >> >> - Fragmentation of RADIUS packets to support exchanges exceeding the e= xisting 4KB limit imposed by RFC2865. >> >> Goals and Milestones >> Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication >> Done SIP RADIUS authentication draft submitted as a Proposed Standard = RFC >> Done RFC 2486bis submitted as a Proposed Standard RFC >> Done RFC 3576 MIBs submitted as an Informational RFC >> Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed= Standard RFC (reduced in scope) >> Done RADIUS Implementation Issues and Fixes draft submitted as an Info= rmational RFC >> Done RADIUS Filtering Attributes draft submitted as a Proposed Standar= d RFC (split out from VLAN & Priority draft) >> Done RFC 3576bis submitted as an Informational RFC (split out from Iss= ues & Fixes draft) >> Done RADIUS Redirection Attributes draft submitted as a Proposed Stand= ard RFC (split out from VLAN & Priority draft) >> Done RADIUS Design Guidelines submitted as a Best Current Practice RFC= >> Done RADIUS Management Authorization I-D submitted as a Proposed Stand= ard RFC >> Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed= Standard RFC >> Done Status-Server I-D submitted as a Proposed Standard RFC >> Done RADIUS Crypto-agility Requirements submitted as an Informational = RFC >> Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental R= FC >> Aug 2012 IPv6 Access I-D submitted as a Proposed Standard RFC >> Aug 2012 Extended Attributes I-D submitted as a Proposed Standard RFC >> Aug 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC >> Sep 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC >> Oct 2012 RADIUS over DTLS I-D submitted as an Experimental RFC >> Dec 2012 Traffic Statistics Attribute I-D submitted as a Proposed Stan= dard RFC >> Dec 2012 RADIUS packet fragmentation submitted as an Experimental RFC >> Jan 2012 RFC 4282bis submitted as a Proposed Standard RFC >> Apr 2013 RADIUS support for NAI Internationalization I-D submitted as = a Proposed Standard RFC >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> >> >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigCEE9FA6798D5CA61E8DA77E6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBpgScACgkQ+jm90f8eFWZeMQCdFHkpOhPtSLHaaG6Kgt7pflGu fIsAnREVWvGtduSjgE/UK21i/guE3PJM =jhCa -----END PGP SIGNATURE----- --------------enigCEE9FA6798D5CA61E8DA77E6-- From stefan.winter@restena.lu Mon Oct 1 04:49:56 2012 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 1278E21F84FC for ; Mon, 1 Oct 2012 04:49:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROkf9jOw005q for ; Mon, 1 Oct 2012 04:49:55 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id E674121F84C2 for ; Mon, 1 Oct 2012 04:49:47 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 144431058B for ; Mon, 1 Oct 2012 13:49:47 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e] (unknown [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e]) by smtprelay.restena.lu (Postfix) with ESMTPS id 0216110581 for ; Mon, 1 Oct 2012 13:49:47 +0200 (CEST) Message-ID: <5069835A.5020308@restena.lu> Date: Mon, 01 Oct 2012 13:49:46 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: radext@ietf.org References: <5066FE87.6040309@cisco.com> In-Reply-To: <5066FE87.6040309@cisco.com> X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig77318B44B0B5AED2166F8129" X-Virus-Scanned: ClamAV Subject: [radext] IPFIX for radius accounting classes 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, 01 Oct 2012 11:49:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig77318B44B0B5AED2166F8129 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > 2. If we go for the flexible approach, where do we stop in terms of > flexibility? > Should the URN in WInter's draft contain: then ipv4 versus ipv6, then > all the DSCP values, then the next hop, then AS-path ... All of which > To finally end up with the IPFIX flexibility, i.e. a template based > mechanism, based on any selection of all IPFIX IANA IEs > Reusing IPFIX definitions sounds good to me, under some conditions. 1. The information in the Accounting packet should not be required to contain the entire definition of that flow; a label of sorts should attached / admin-defined and that label should be used. 2. The question of how to configure the NAS for such accounting should be out of scope for the accounting document. I could imagine it to happen within an Access-Accept for a specific user, or as a configuration action by the administrator on the NAS. In any case, not within an Accounting message; and since this draft is about Accounting, it should happen somewhere else. I believe 2. was discussed lately, and agreed upon already. If that's true, the discussion would boil down to - "How to map from an IPFIX flow definition to a handle / label?" - "How to transport the label and related accounting data from client to server?" Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig77318B44B0B5AED2166F8129 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBpg1oACgkQ+jm90f8eFWbj7ACfa/6H9VFeLmXXN45c8grrcsEF puUAniFAnhyLm3+P1oRSGtApLGnjcKso =5Ma0 -----END PGP SIGNATURE----- --------------enig77318B44B0B5AED2166F8129-- From stefan.winter@restena.lu Mon Oct 1 04:52:53 2012 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 4099E21F85F0 for ; Mon, 1 Oct 2012 04:52:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwvk-G5SCzO5 for ; Mon, 1 Oct 2012 04:52:51 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id E559D21F84FC for ; Mon, 1 Oct 2012 04:52:49 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 49FA91058B for ; Mon, 1 Oct 2012 13:52:49 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e] (unknown [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e]) by smtprelay.restena.lu (Postfix) with ESMTPS id 36A5810581 for ; Mon, 1 Oct 2012 13:52:49 +0200 (CEST) Message-ID: <50698410.1050502@restena.lu> Date: Mon, 01 Oct 2012 13:52:48 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: radext@ietf.org References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> In-Reply-To: <50696897.9000600@deployingradius.com> X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE7AA5EBBE3D2ED85C22CCE52" X-Virus-Scanned: ClamAV Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 11:52:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE7AA5EBBE3D2ED85C22CCE52 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > The issue (I think) is more broken proxies. e.g. proxies as seen in > Eduroam, which have self-allocated "unused" attributes. That part I understand; Sam mentioned possible corruption in anbsence of an attacker. What I don't understand is the extra complications of an actively malicious entity which would turn the problem from a "just" interop problem to a security threat. Greetings, Stefan >=20 > They expect the self-allocated attributes to be in a particular form.= > They do bad things when they see IETF versions of those attributes. >=20 > My $0.02 is that detecting this is probably a good idea. Catching > mangled fragments is nice. Preventing mangled fragments from causing > decode errors is nice. >=20 > But... in general, proxies mangling attributes they don't understand > is stupid. People running those proxies should upgrade to RFC complian= t > RADIUS servers. >=20 > e.g. For years the Merit RADIUS server *explicitly* violated the RFCs= =2E > Any Proxy-State was treated as an ASCII version of an 8-bit number, > such as "42". Packets *not* meeting that criteria were mishandled. >=20 > This was an issue for a few years on mailing lists I'm on. The > solution was always simple: Upgrade to a real RADIUS server. >=20 > People did. >=20 > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigE7AA5EBBE3D2ED85C22CCE52 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBphBEACgkQ+jm90f8eFWZvkgCeIO+xG2fIk09pzkO0XLPSeFfU SB0An1yCki+jUsLFEhxBzci6xoO52VIt =Z2kx -----END PGP SIGNATURE----- --------------enigE7AA5EBBE3D2ED85C22CCE52-- From aland@deployingradius.com Mon Oct 1 05:02:06 2012 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 F0EC621F867F for ; Mon, 1 Oct 2012 05:02:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyNDNVAf6t7X for ; Mon, 1 Oct 2012 05:02:04 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id A51DC21F867E for ; Mon, 1 Oct 2012 05:02:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D47B52240D01; Mon, 1 Oct 2012 14:01:12 +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 NayUh7feo3cJ; Mon, 1 Oct 2012 14:01:12 +0200 (CEST) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by power.freeradius.org (Postfix) with ESMTPSA id 8ACA92240797; Mon, 1 Oct 2012 14:01:12 +0200 (CEST) Message-ID: <50698611.5070000@deployingradius.com> Date: Mon, 01 Oct 2012 14:01:21 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter , "radext@ietf.org" References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> <50698410.1050502@restena.lu> In-Reply-To: <50698410.1050502@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 12:02:06 -0000 Stefan Winter wrote: > That part I understand; Sam mentioned possible corruption in anbsence of > an attacker. > > What I don't understand is the extra complications of an actively > malicious entity which would turn the problem from a "just" interop > problem to a security threat. I think it's a combination of the two. An attacker who sends data, knowing that a broken proxy will mangle the attribute. He may not have control over the proxy, but he may know how it works. For example, if the attacker knows that a proxy throws away the first fragment, he can set up the data so that the second fragment falsely seems to be the first one. The contents are under his control, and he can create any VSA he wants. It's an admittedly esoteric attack. But that's what security is about. Alan DeKok. From aland@deployingradius.com Mon Oct 1 05:17:16 2012 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 E5FE521F865F for ; Mon, 1 Oct 2012 05:17:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO6fkDQ3XLoF for ; Mon, 1 Oct 2012 05:17:14 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9136821F87E8 for ; Mon, 1 Oct 2012 05:17:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 235B22240D01; Mon, 1 Oct 2012 14:16:21 +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 i7O022F2yS7i; Mon, 1 Oct 2012 14:16:20 +0200 (CEST) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by power.freeradius.org (Postfix) with ESMTPSA id 3A84F2240797; Mon, 1 Oct 2012 14:16:20 +0200 (CEST) Message-ID: <5069899C.9020606@deployingradius.com> Date: Mon, 01 Oct 2012 14:16:28 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <5066FE87.6040309@cisco.com> <5069835A.5020308@restena.lu> In-Reply-To: <5069835A.5020308@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] IPFIX for radius accounting classes 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, 01 Oct 2012 12:17:16 -0000 Stefan Winter wrote: > 1. The information in the Accounting packet should not be required to > contain the entire definition of that flow; a label of sorts should > attached / admin-defined and that label should be used. IPFIX has a 64-bit "flowID" field. That should work. My only hard requirement is that the flowID is either set by the administrator, or by the RADIUS server in an Access-Request. NASes shouldn't invent it themselves. > 2. The question of how to configure the NAS for such accounting should > be out of scope for the accounting document. I could imagine it to > happen within an Access-Accept for a specific user, or as a > configuration action by the administrator on the NAS. In any case, not > within an Accounting message; and since this draft is about Accounting, > it should happen somewhere else. I agree. > I believe 2. was discussed lately, and agreed upon already. If that's > true, the discussion would boil down to > > - "How to map from an IPFIX flow definition to a handle / label?" > > - "How to transport the label and related accounting data from client to > server?" I've done some research. I think I have a reasonable solution. I'll try to post a -00 before October 8. Alan DeKok. From stefan.winter@restena.lu Mon Oct 1 05:24:27 2012 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 B2E5721F8775 for ; Mon, 1 Oct 2012 05:24:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq8Apd9ip3eI for ; Mon, 1 Oct 2012 05:24:27 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id DCD2C11E80B8 for ; Mon, 1 Oct 2012 05:24:26 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 11CCE1058B for ; Mon, 1 Oct 2012 14:24:25 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e] (unknown [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e]) by smtprelay.restena.lu (Postfix) with ESMTPS id 0342710581 for ; Mon, 1 Oct 2012 14:24:25 +0200 (CEST) Message-ID: <50698B78.1030803@restena.lu> Date: Mon, 01 Oct 2012 14:24:24 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: radext@ietf.org References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> <50698410.1050502@restena.lu> <50698611.5070000@deployingradius.com> In-Reply-To: <50698611.5070000@deployingradius.com> X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig82AB0F3AD0FA41D79F56D7E4" X-Virus-Scanned: ClamAV Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 12:24:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig82AB0F3AD0FA41D79F56D7E4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I think it's a combination of the two. An attacker who sends data, > knowing that a broken proxy will mangle the attribute. He may not have= > control over the proxy, but he may know how it works. >=20 > For example, if the attacker knows that a proxy throws away the first= > fragment, he can set up the data so that the second fragment falsely > seems to be the first one. The contents are under his control, and he > can create any VSA he wants. >=20 > It's an admittedly esoteric attack. But that's what security is abou= t. Even in this case, doesn't the same reasoning apply? If the entity before the broken proxy is a RADIUS server or proxy, it has the entire packet in its hands and can rewrite it to its liking. It doesn't have to resort to "tricks" to make someone else do the rewrite. And if it's not a RADIUS entity, Message-Authenticator would prevent the mangling of anything in the packet en route. Greetings, Stefan Winter >=20 > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig82AB0F3AD0FA41D79F56D7E4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBpi3gACgkQ+jm90f8eFWYvPwCgheJ/t6RRmiPvLCXFJHFRx+qL KbwAn1vXbVDVfwWGWXYQlQoldER08sAa =JGns -----END PGP SIGNATURE----- --------------enig82AB0F3AD0FA41D79F56D7E4-- From hartmans@painless-security.com Mon Oct 1 05:45:03 2012 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 AFB3421F881D for ; Mon, 1 Oct 2012 05:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.394 X-Spam-Level: **** X-Spam-Status: No, score=4.394 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TcF07TwHZdu for ; Mon, 1 Oct 2012 05:45:03 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id F335321F8814 for ; Mon, 1 Oct 2012 05:45:02 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 437A420289; Mon, 1 Oct 2012 08:44:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9A871414A; Mon, 1 Oct 2012 08:44:57 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> Date: Mon, 01 Oct 2012 08:44:57 -0400 In-Reply-To: <50696649.5050001@restena.lu> (Stefan Winter's message of "Mon, 01 Oct 2012 11:45:45 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 12:45:03 -0000 >>>>> "Stefan" == Stefan Winter writes: Stefan> Hi, >> So, you send an extensions packet to a non-extensions proxy. >> That proxy happens to reorder the packets in a manner that some >> attacker understands but that the sending system and final server >> do not. This is likely to lead to corruption even without an >> attacker. IN the presence of an attacker, who controlled inputs >> that got packaged up in the fragmented attributes, the attacker >> may be able to inject a fragmented attribute not present in the >> original packet of the attacker's choosing. Stefan> If the RADIUS proxy itself is the malicious entity, it can Stefan> inject or remove any attribute it so likes; whether it's Stefan> extended attribs or not. Stefan> If the attacker is an intermediate IP node, any Stefan> manipulations would change the Message-Authenticator Stefan> attribute, right? Stefan> I feel like I'm missing something... could someone enlighten Stefan> me? I'm imagining a phone company exec in the 60's or 70's trying to figure out why the calls charged to a pay phone sometimes doesn't match the take from the coin box after physical shrinkage has been removed as a factor. "I feel like I'm missing something," he says. Your analysis considers attackers along the path of the message, but ignores attackers producing their 2600 hz tones before the beginning or after the end. This is an encapsulation mechanism that can potentially carry untrusted data. One of the most serious attacks on systems like that are cases where as part of the untrusted data supplied by the attacker can be re-interpreted as control information for the encapsulation system itself. Imagine a malicious Moonshot IDP who knows a proxy re-orders packets. It can add additional attributes of the appropriate type to the response. Similarly if a RADIUS client takes any information supplied by a potential attacker and sticks it into the fragmented attribute, you can get problems of this type. --Sam From hartmans@painless-security.com Mon Oct 1 05:48:14 2012 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 B14CD11E8114 for ; Mon, 1 Oct 2012 05:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.39 X-Spam-Level: **** X-Spam-Status: No, score=4.39 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zim+qxibhQck for ; Mon, 1 Oct 2012 05:48:14 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 2515B11E8115 for ; Mon, 1 Oct 2012 05:48:14 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 932E120289; Mon, 1 Oct 2012 08:48:01 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E6BFF414A; Mon, 1 Oct 2012 08:48:08 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> <50698410.1050502@restena.lu> <50698611.5070000@deployingradius.com> Date: Mon, 01 Oct 2012 08:48:08 -0400 In-Reply-To: <50698611.5070000@deployingradius.com> (Alan DeKok's message of "Mon, 01 Oct 2012 14:01:21 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 12:48:15 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Stefan Winter wrote: >> That part I understand; Sam mentioned possible corruption in >> anbsence of an attacker. >> >> What I don't understand is the extra complications of an actively >> malicious entity which would turn the problem from a "just" >> interop problem to a security threat. Alan> I think it's a combination of the two. An attacker who Alan> sends data, knowing that a broken proxy will mangle the Alan> attribute. He may not have control over the proxy, but he may Alan> know how it works. Alan> For example, if the attacker knows that a proxy throws away Alan> the first fragment, he can set up the data so that the second Alan> fragment falsely seems to be the first one. The contents are Alan> under his control, and he can create any VSA he wants. Or the attacker could just know that the proxy will reorder fragments. The proxy need not even be broken under the current RFCs. From aland@deployingradius.com Mon Oct 1 05:57:33 2012 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 C9DA811E8231 for ; Mon, 1 Oct 2012 05:57:33 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POiUxadoSb-7 for ; Mon, 1 Oct 2012 05:57:33 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF9B11E8242 for ; Mon, 1 Oct 2012 05:57:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id ADCD62240D01; Mon, 1 Oct 2012 14:56:13 +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 wHCbhRSnMp7m; Mon, 1 Oct 2012 14:56:11 +0200 (CEST) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by power.freeradius.org (Postfix) with ESMTPSA id BA7232240797; Mon, 1 Oct 2012 14:56:11 +0200 (CEST) Message-ID: <506992F4.3010701@deployingradius.com> Date: Mon, 01 Oct 2012 14:56:20 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> <50698410.1050502@restena.lu> <50698611.5070000@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 12:57:34 -0000 Sam Hartman wrote: > Or the attacker could just know that the proxy will reorder fragments. > The proxy need not even be broken under the current RFCs. But re-ordering attributes *is* forbidden under current RFCS. Alan DeKok. From aland@deployingradius.com Mon Oct 1 05:58:56 2012 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 07C4F11E81A5 for ; Mon, 1 Oct 2012 05:58:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDU2JFSEkJ-A for ; Mon, 1 Oct 2012 05:58:55 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF03D11E8211 for ; Mon, 1 Oct 2012 05:58:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 37E252240D01; Mon, 1 Oct 2012 14:57:44 +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 ZmZtJwtUlqqU; Mon, 1 Oct 2012 14:57:44 +0200 (CEST) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by power.freeradius.org (Postfix) with ESMTPSA id E71F22240797; Mon, 1 Oct 2012 14:57:43 +0200 (CEST) Message-ID: <50699350.6020205@deployingradius.com> Date: Mon, 01 Oct 2012 14:57:52 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> <50698410.1050502@restena.lu> <50698611.5070000@deployingradius.com> <50698B78.1030803@restena.lu> In-Reply-To: <50698B78.1030803@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 12:58:56 -0000 Stefan Winter wrote: > Even in this case, doesn't the same reasoning apply? If the entity > before the broken proxy is a RADIUS server or proxy, it has the entire > packet in its hands and can rewrite it to its liking. It doesn't have to > resort to "tricks" to make someone else do the rewrite. The issue is a working NAS, which sends valid fragments. A broken proxy discards fragment 1. The attacker knows this, and sends data such that the contents of fragment 2 are decoded as a VSA. The NAS doesn't look at the second fragment, because it's just taking user data && fragmenting it. Alan DeKok. From hartmans@painless-security.com Mon Oct 1 06:07:21 2012 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 E60C31F0CB7 for ; Mon, 1 Oct 2012 06:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.386 X-Spam-Level: **** X-Spam-Status: No, score=4.386 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Avo5LwCnQxCj for ; Mon, 1 Oct 2012 06:07:21 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6852A11E816B for ; Mon, 1 Oct 2012 06:07:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id BD31820289; Mon, 1 Oct 2012 08:59:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F386A414A; Mon, 1 Oct 2012 08:59:49 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> <50698410.1050502@restena.lu> <50698611.5070000@deployingradius.com> <506992F4.3010701@deployingradius.com> Date: Mon, 01 Oct 2012 08:59:49 -0400 In-Reply-To: <506992F4.3010701@deployingradius.com> (Alan DeKok's message of "Mon, 01 Oct 2012 14:56:20 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 13:07:22 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: >> Or the attacker could just know that the proxy will reorder >> fragments. The proxy need not even be broken under the current >> RFCs. Alan> But re-ordering attributes *is* forbidden under current Alan> RFCS. OK, then I'm confused. Peter, can you try and explain your issue more clearly? From leaf.yeh.sdo@gmail.com Mon Oct 1 06:33:57 2012 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 B020A21F88A1 for ; Mon, 1 Oct 2012 06:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnBM4nsMQqtG for ; Mon, 1 Oct 2012 06:33:55 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 86A7D1F0D65 for ; Mon, 1 Oct 2012 06:33:40 -0700 (PDT) Received: by padfb11 with SMTP id fb11so4305939pad.31 for ; Mon, 01 Oct 2012 06:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=x4cBNAJ01FVGlkMoND19AgCLMAk96iJBKZWwPydatSE=; b=HuJHtw+AeIjWfeGf6cOpXzRSbONwV0ZE8+fVSlsgBTAb/qaIBHHBVwG30VBHm/+h0P Gwclk1CZlYvSO21igsScjLnzirDGEZt1LQp6PYK0g2nkXupgbZrashpM+hKwM12tLbhv 6eczAi7RKoPNdvGnjkkw74KuLXpgUCLajdK575oypDbSAi7/EfVOAuTLT21um+e6boqT 3qNURNdw65NuX2lrKNA9DyM6VydjYTrgy5ywH4TGHfk04VF7jodIA6liFSKGZc+hesAo 1BmEQGjIqeMUV4x748/7vfxb/DCmlwsk2FCIQurnjhhH5RZqCocCWqM0ADE2yyznXqgU DqVg== Received: by 10.68.193.194 with SMTP id hq2mr41551295pbc.93.1349098420007; Mon, 01 Oct 2012 06:33:40 -0700 (PDT) Received: from lst9242355d22a ([218.18.217.243]) by mx.google.com with ESMTPS id i2sm10403110pav.13.2012.10.01.06.33.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 06:33:39 -0700 (PDT) From: "Leaf Yeh" To: References: <5066FE87.6040309@cisco.com> <50698127.9040705@restena.lu> In-Reply-To: <50698127.9040705@restena.lu> Date: Mon, 1 Oct 2012 21:33:37 +0800 Message-ID: <50699bb3.2249420a.3ed2.ffffc0f0@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2fyY+YaI1QnfRnTnKUjYcgr1wsbQADrQXw Content-Language: zh-cn Subject: Re: [radext] new charter proposal 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, 01 Oct 2012 13:33:57 -0000 The mail below recorded us one more support to make the item of 'RADIUS Accounting Extensions for Traffic Statistics' into the Radext new = charter. :-) Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf = Of Stefan Winter Sent: Monday, October 01, 2012 7:40 PM To: radext@ietf.org Subject: Re: [radext] new charter proposal Hi, > Since we also discussed this new charter during the IETF meeting, I'll = > take the lack of replies as agreement. >=20 > However, I have a concern regarding the RADIUS Accounting Extensions=20 > for Traffic Statistics, for two reasons: > 1. there are two competing proposals, tactical approach vs. flexible=20 > approach, as mentioned in the meeting minutes. And there is ongoing=20 > discussion on the mailing regarding the direction to take. If I recall the meeting correctly (remote participation only), I believe there was an extensive discussion and a show of hands which direction to take. I heard after the meeting that the result was 4:1 in favour of a flexivle approach. That show of hands was to be confirmed on the list, but IIRC, this = hasn't happened yet. I'd suggest a corresponding poll on the list, and take the result of = that as the basis for the new charter. > 2. If we go for the flexible approach, where do we stop in terms of=20 > flexibility? > Should the URN in WInter's draft contain: then ipv4 versus ipv6, then=20 > all the DSCP values, then the next hop, then AS-path ... All of which=20 > To finally end up with the IPFIX flexibility, i.e. a template based=20 > mechanism, based on any selection of all IPFIX IANA IEs=20 > > So I would like the WG to agree on the problem statement first. I believe that once the principle direction "flexible vs. one-purpose" is settle, the *details* of how that flexibility should look like could = be part of the normal WG work and doesn't have to explicitly called out in = the charter. Greetings, Stefan Winter >=20 > Since both the NAI and the fragmentation work is agreed upon, we could = > proceed with the new charter, modulo the "RADIUS Accounting Extensions = > for Traffic Statistics" >=20 > Regards, Benoit. >=20 >> Description of Working Group >> >> The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to expand and enrich the standard attribute = space, address cryptographic algorithm agility, use of new secure transports = and clarify its usage and definition. >> >> In order to maintain interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items except those that just define new attributes MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. >> >> Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, = the following restrictions are imposed on extensions considered by the = RADEXT WG: >> >> - All documents produced MUST specify means of interoperation with = legacy RADIUS and, if possible, be backward compatible with existing RADIUS = RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be = compatible with RFC 3539. >> >> Work Items >> The immediate goals of the RADEXT working group are to address the following issues: >> >> - RADIUS attribute space extension. The standard RADIUS attribute = space is currently being depleted. This document will provide additional = standard attribute space, while maintaining backward compatibility with existing attributes. >> >> - IEEE 802 attributes. New attributes have been proposed to support = IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE = 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. >> >> - New RADIUS transports. A reliable transport profile for RADIUS will = be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS. >> >> - Update and clarification of Network Access Identifiers = (RFC4282).This work item will correct and clarify issues present with RFC4282 in two phases. In first phase, RFC4282bis will be issued to eliminate = fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies. In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS. >> >> - RADIUS Accounting Extensions for Traffic Statistics. This work item will specify RADIUS accounting attributes for differentiated accounting polices and traffic recording. >> >> - Fragmentation of RADIUS packets to support exchanges exceeding the existing 4KB limit imposed by RFC2865. >> >> Goals and Milestones >> Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication=20 >> Done SIP RADIUS authentication draft submitted as a Proposed Standard = >> RFC Done RFC 2486bis submitted as a Proposed Standard RFC Done RFC=20 >> 3576 MIBs submitted as an Informational RFC Done RADIUS VLAN and=20 >> Priority Attributes draft submitted as a Proposed Standard RFC=20 >> (reduced in scope) Done RADIUS Implementation Issues and Fixes draft=20 >> submitted as an Informational RFC Done RADIUS Filtering Attributes=20 >> draft submitted as a Proposed Standard RFC (split out from VLAN &=20 >> Priority draft) Done RFC 3576bis submitted as an Informational RFC=20 >> (split out from Issues & Fixes draft) Done RADIUS Redirection=20 >> Attributes draft submitted as a Proposed Standard RFC (split out from = >> VLAN & Priority draft) Done RADIUS Design Guidelines submitted as a=20 >> Best Current Practice RFC Done RADIUS Management Authorization I-D=20 >> submitted as a Proposed Standard RFC Done Reliable Transport Profile=20 >> for RADIUS I-D submitted as a Proposed Standard RFC Done=20 >> Status-Server I-D submitted as a Proposed Standard RFC Done RADIUS=20 >> Crypto-agility Requirements submitted as an Informational RFC Done=20 >> RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC=20 >> Aug 2012 IPv6 Access I-D submitted as a Proposed Standard RFC Aug=20 >> 2012 Extended Attributes I-D submitted as a Proposed Standard RFC Aug = >> 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC Sep=20 >> 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Oct = >> 2012 RADIUS over DTLS I-D submitted as an Experimental RFC Dec 2012=20 >> Traffic Statistics Attribute I-D submitted as a Proposed Standard RFC = >> Dec 2012 RADIUS packet fragmentation submitted as an Experimental RFC = >> Jan 2012 RFC 4282bis submitted as a Proposed Standard RFC Apr 2013=20 >> RADIUS support for NAI Internationalization I-D submitted as a=20 >> Proposed Standard RFC >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> >> >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From avi.ietf@lior.org Mon Oct 1 07:17:45 2012 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 278D211E8112 for ; Mon, 1 Oct 2012 07:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdL4Eq-5xedm for ; Mon, 1 Oct 2012 07:17:43 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC24011E810E for ; Mon, 1 Oct 2012 07:17:43 -0700 (PDT) Received: by iado25 with SMTP id o25so477818iad.31 for ; Mon, 01 Oct 2012 07:17:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=WmWg7wMhioHGghZHZH9k0ZOnBm2d62ShUIroGTM1UOg=; b=RaAPWmHAO7jktSiEpVI+NCkL9wIly1Pe+x3jXmznizfBRS/RWZIxlJNE19CW6Vrrqc qVbvA8A25NrWFo/jVzOdMaQHbb8WdU6hgmzEwBbSZtXBKA+Z6cduRgfU70xwfWWvwXoT vkznc4AlUTxg9N6evWLxuw2ucXxIEovN2w/xU0HSiNRi8HJ1egu9tx0NzXkmN+V1U/rH reL2YK1IU4x/zJJ85a8Yfd+w2iKV4BR3TmyKTrNu7prww013nX/P1/KMN2cIUb040we4 TJ7bBmVJIPL9rb9fj7iGKC3cpnTYGD3qHW2Dy5kz2hJzz3+tJlfD1jWOEqY6HWvs2QYb /+Xg== Received: by 10.50.40.163 with SMTP id y3mr5882352igk.32.1349101063298; Mon, 01 Oct 2012 07:17:43 -0700 (PDT) Received: from [172.17.17.120] (CPE10bf48d33c88-CM602ad089cf9c.cpe.net.cable.rogers.com. [99.224.172.207]) by mx.google.com with ESMTPS id 7sm8283013igh.0.2012.10.01.07.17.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 07:17:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Avi Lior In-Reply-To: <50696897.9000600@deployingradius.com> Date: Mon, 1 Oct 2012 10:17:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1498) X-Gm-Message-State: ALoCoQn8H2w+scYJb7oqZT7xWh6tzscsTjVv9QJKedCzcDAC7V447JipH+SSGZ18yrFKhvWlZB2a Cc: Stefan Winter , radext@ietf.org Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 14:17:45 -0000 In the case where we are sending a message spanning several packets = wouldn't it be prudent to have a message authenticator computed over the = entire set. The last packet would contains the computed authenticator. On 2012-10-01, at 5:55 , Alan DeKok wrote: > Stefan Winter wrote: >> If the RADIUS proxy itself is the malicious entity, it can inject or >> remove any attribute it so likes; whether it's extended attribs or = not. >=20 > The issue (I think) is more broken proxies. e.g. proxies as seen in > Eduroam, which have self-allocated "unused" attributes. >=20 > They expect the self-allocated attributes to be in a particular form. > They do bad things when they see IETF versions of those attributes. >=20 > My $0.02 is that detecting this is probably a good idea. Catching > mangled fragments is nice. Preventing mangled fragments from causing > decode errors is nice. >=20 > But... in general, proxies mangling attributes they don't understand > is stupid. People running those proxies should upgrade to RFC = compliant > RADIUS servers. >=20 > e.g. For years the Merit RADIUS server *explicitly* violated the = RFCs. > Any Proxy-State was treated as an ASCII version of an 8-bit number, > such as "42". Packets *not* meeting that criteria were mishandled. >=20 > This was an issue for a few years on mailing lists I'm on. The > solution was always simple: Upgrade to a real RADIUS server. >=20 > People did. >=20 > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From avi.ietf@lior.org Mon Oct 1 07:28:21 2012 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 379A01F0CF9 for ; Mon, 1 Oct 2012 07:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgoTCkvqWSPk for ; Mon, 1 Oct 2012 07:28:20 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEF161F0CD6 for ; Mon, 1 Oct 2012 07:28:20 -0700 (PDT) Received: by iec9 with SMTP id 9so14138831iec.31 for ; Mon, 01 Oct 2012 07:28:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ENCAvJLc93suPercrBRJyf3Se40UEiBQsKrqdfZmcc4=; b=Vml+U+MNDS5Zl/9M9S/RSlHSGgO7omN8EDg+5G0tDVb7qjNbl+7YeF6X3PEXsqGqtg p1TgteV7bkTINs7lJQbSefHif+QKqMZGZDKtfYIVZ2qlHBqatfxu+BoDh+WLH9nDQqHs pXQkyX+HRJ6THlvWAxLcNtVOEjEsdAWe6EwwZ6wp6NvN+bQ8YI2dNUMrz0MDDZNtEymY UlfzxOavZ2h/s3dnLN4qX5WjARmq+Lq5K2+W5C1GNmx2AOV6EHgFvatfQrZ0YTR7vckl NiL2zDLsKwkVf4ayib0tZm2imKWDzkm+YdE/BcHc6B1JOKxtklBBpsUGgpcNdL/DAvP0 l/Rg== Received: by 10.50.77.230 with SMTP id v6mr4009340igw.11.1349101699890; Mon, 01 Oct 2012 07:28:19 -0700 (PDT) Received: from [172.17.17.120] (CPE10bf48d33c88-CM602ad089cf9c.cpe.net.cable.rogers.com. [99.224.172.207]) by mx.google.com with ESMTPS id o9sm6605942igd.7.2012.10.01.07.28.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 07:28:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Avi Lior In-Reply-To: Date: Mon, 1 Oct 2012 10:28:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <83E461C9-9EDA-427C-8E85-9CC6874D8799@lior.org> References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> <50698410.1050502@restena.lu> <50698611.5070000@deployingradius.com> <506992F4.3010701@deployingradius.com> To: Sam Hartman X-Mailer: Apple Mail (2.1498) X-Gm-Message-State: ALoCoQmc5AKaJKHA85ChH8gsN2/cAvMW9eaYPrGhUHHcNoojRwOiJiii56USswH185Hz0tG4lAXn Cc: Stefan Winter , "radext@ietf.org" , Alan DeKok Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 14:28:21 -0000 Me too. Here is what I know: RADIUS is hop-by-hop and each hop is trusted. RADIUS "hops" must preserve the order of attributes. If we are sending messages that span multiple RADIUS packets then the = packets can be reordered on purpose or by accident by a = man-in-the-middle. We need to mitigate that. I suppose sequence = numbers on the packet and/or an authenticator computed on the sequence = of packets. ? =20 On 2012-10-01, at 8:59 , Sam Hartman = wrote: >>>>>> "Alan" =3D=3D Alan DeKok writes: >=20 > Alan> Sam Hartman wrote: >>> Or the attacker could just know that the proxy will reorder >>> fragments. The proxy need not even be broken under the current >>> RFCs. >=20 > Alan> But re-ordering attributes *is* forbidden under current > Alan> RFCS. >=20 > OK, then I'm confused. > Peter, can you try and explain your issue more clearly? >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Mon Oct 1 07:45:35 2012 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 3EAC01F0CF9 for ; Mon, 1 Oct 2012 07:45:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMMYeSkU9D0g for ; Mon, 1 Oct 2012 07:45:34 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1E9E21F887B for ; Mon, 1 Oct 2012 07:45:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 7CD042240D01; Mon, 1 Oct 2012 16:45:33 +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 YmCzZZJVocla; Mon, 1 Oct 2012 16:45:33 +0200 (CEST) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by power.freeradius.org (Postfix) with ESMTPSA id 384152240797; Mon, 1 Oct 2012 16:45:33 +0200 (CEST) Message-ID: <5069AC95.10803@deployingradius.com> Date: Mon, 01 Oct 2012 16:45:41 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Avi Lior , "radext@ietf.org" References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> <50698410.1050502@restena.lu> <50698611.5070000@deployingradius.com> <506992F4.3010701@deployingradius.com> <83E461C9-9EDA-427C-8E85-9CC6874D8799@lior.org> In-Reply-To: <83E461C9-9EDA-427C-8E85-9CC6874D8799@lior.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 14:45:35 -0000 Avi Lior wrote: > If we are sending messages that span multiple RADIUS packets We're not saying that in this draft. I'd like to avoid that subject, if at all possible. Alan DeKok. From avi.ietf@lior.org Mon Oct 1 07:51:58 2012 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 888CF1F0D31 for ; Mon, 1 Oct 2012 07:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoboyPLZnNZd for ; Mon, 1 Oct 2012 07:51:58 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8ADE1F0D36 for ; Mon, 1 Oct 2012 07:51:57 -0700 (PDT) Received: by iec9 with SMTP id 9so14215379iec.31 for ; Mon, 01 Oct 2012 07:51:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=zwU7+QiPsUsbSttq50jDQCs1ALCdaQPRI2PnLePF0tA=; b=e1ArFViAXuJu8oz/edysMQdrg+E5DiuSax/8Gi1tEDvO+vevgK+jOwxE/tebLsa8CQ P6jhuvkRlFjStd2Gw4jVJJqmTBp63eNdnoiu2XLV0LemOYwzTRdz4BX+qf+RzWKE+bBg PVtadnzuDlBC1N6vf5goWo0xi/5IVX8sNBmweneY7ZBBfecjnXxyMVYNfrViZYwETkxE HmmtIef2rn8DtU7NMRMseRh/HbqMSBg1LAbRD+QpAy+CdnJgzN6PHhTiUWXQO6J0Gfyv F226/6DteH1XWzT+oEQT6TOfHdF3czkAvPpVDOLG4MjSYtG6GSbF8a57yeVhkcKdiysZ sZCg== Received: by 10.50.95.231 with SMTP id dn7mr6049330igb.36.1349103115754; Mon, 01 Oct 2012 07:51:55 -0700 (PDT) Received: from [172.17.17.120] (CPE10bf48d33c88-CM602ad089cf9c.cpe.net.cable.rogers.com. [99.224.172.207]) by mx.google.com with ESMTPS id bo7sm7142300igb.2.2012.10.01.07.51.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 07:51:54 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Avi Lior In-Reply-To: <5069AC95.10803@deployingradius.com> Date: Mon, 1 Oct 2012 10:51:52 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> <50698410.1050502@restena.lu> <50698611.5070000@deployingradius.com> <506992F4.3010701@deployingradius.com> <83E461C9-9EDA-427C-8E85-9CC6874D8799@lior.org> <5069AC95.10803@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1498) X-Gm-Message-State: ALoCoQlyisxdyMNjmBfEsp3NYCoar4/+ah7ZKxGUQbdeyyOuy30K+8udTqb88iHwYnsIJVKLXnay Cc: "radext@ietf.org" Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 14:51:58 -0000 I agree. I fell into that trap by commenting on the discussion. That should be a separate document. On 2012-10-01, at 10:45 , Alan DeKok wrote: > Avi Lior wrote: >> If we are sending messages that span multiple RADIUS packets > > We're not saying that in this draft. > > I'd like to avoid that subject, if at all possible. > > Alan DeKok. From stefan.winter@restena.lu Mon Oct 1 08:04:52 2012 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 570311F0D0A for ; Mon, 1 Oct 2012 08:04:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Shs2TB+j71oq for ; Mon, 1 Oct 2012 08:04:51 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 523251F0CD6 for ; Mon, 1 Oct 2012 08:04:51 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 00BC91058B for ; Mon, 1 Oct 2012 17:04:50 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e] (unknown [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e]) by smtprelay.restena.lu (Postfix) with ESMTPS id E4A0210581 for ; Mon, 1 Oct 2012 17:04:49 +0200 (CEST) Message-ID: <5069B111.7040309@restena.lu> Date: Mon, 01 Oct 2012 17:04:49 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: radext@ietf.org References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig043A6D3BE9B3A57D404A64A2" X-Virus-Scanned: ClamAV Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 15:04:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig043A6D3BE9B3A57D404A64A2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Your analysis considers attackers along the path of the message, but > ignores attackers producing their 2600 hz tones before the beginning or= > after the end. >=20 > This is an encapsulation mechanism that can potentially carry untrusted= > data. > One of the most serious attacks on systems like that are cases where as= > part of the untrusted data supplied by the attacker can be > re-interpreted as control information for the encapsulation system > itself. >=20 > Imagine a malicious Moonshot IDP who knows a proxy re-orders packets. > It can add additional attributes of the appropriate type to the > response. At least that case is again not specific to the fragmentation problem: an IdP can send whatever it likes itself; it doesn't have to play tricks with the next hop. I assume you are making a point that the RADIUS part of a Moonshot IdP might rely on information from outside, too, say some SAML-producing oracle. The oracle, as an outside party to the RADIUS conversation, could of course produce something large & malicious, that the IdP will send as a fragmented message, which may in turn be misinterpreted by a non-aware proxy. Point taken, now I get it :-) > Similarly if a RADIUS client takes any information supplied by a > potential attacker and sticks it into the fragmented attribute, you can= > get problems of this type. This is symmetrical to the part above, but from the other direction. Well, both threats exist, so they should be taken into account. Whether or not it warrants on-the-wire changes or a mention in security recommendations is enough I don't want to judge. Greetings, Stefan >=20 > --Sam > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig043A6D3BE9B3A57D404A64A2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBpsREACgkQ+jm90f8eFWarTQCfaiyvoH2Zu+knr7DDkC13f29n 7u0AoIcRzJuc8YefhaMUKRXi0y3NLph8 =FSW3 -----END PGP SIGNATURE----- --------------enig043A6D3BE9B3A57D404A64A2-- From hartmans@painless-security.com Mon Oct 1 08:11:33 2012 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 E1ED811E80E7 for ; Mon, 1 Oct 2012 08:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.382 X-Spam-Level: **** X-Spam-Status: No, score=4.382 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niDzc3XzNh2E for ; Mon, 1 Oct 2012 08:11:33 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4692E11E80D5 for ; Mon, 1 Oct 2012 08:11:33 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6AEA920289; Mon, 1 Oct 2012 11:11:20 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F3356414A; Mon, 1 Oct 2012 11:11:27 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <5069B111.7040309@restena.lu> Date: Mon, 01 Oct 2012 11:11:27 -0400 In-Reply-To: <5069B111.7040309@restena.lu> (Stefan Winter's message of "Mon, 01 Oct 2012 17:04:49 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 15:11:34 -0000 >>>>> "Stefan" == Stefan Winter writes: No, what I'm describing is exactly related to the fragmentation problem. The IDP sends an assertion longer than 253 octets (quite probable). The IDP knows which fragment will be dropped/reordered/whatever by the proxy. The IDP constructs an assertion such that the assertion will be interpreted as a different attribute. The IDP is authorized to send any assertion, but is not authorized to send other attributes. Thus, the IDP exceeds its authorization. All this of course depends on Peter coming back with an explanation about how this is possible. From stefan.winter@restena.lu Mon Oct 1 08:21:47 2012 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 A09A811E810E for ; Mon, 1 Oct 2012 08:21:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JK3S5fidUtlQ for ; Mon, 1 Oct 2012 08:21:45 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 32CBE11E80D5 for ; Mon, 1 Oct 2012 08:21:45 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 0F6201058B for ; Mon, 1 Oct 2012 17:21:44 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e] (unknown [IPv6:2001:a18:1:8:e5ba:a496:f44f:be5e]) by smtprelay.restena.lu (Postfix) with ESMTPS id F173410581 for ; Mon, 1 Oct 2012 17:21:43 +0200 (CEST) Message-ID: <5069B507.20607@restena.lu> Date: Mon, 01 Oct 2012 17:21:43 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: radext@ietf.org References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <5069B111.7040309@restena.lu> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5F318DDA334E1ADC6F31EE04" X-Virus-Scanned: ClamAV Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 15:21:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5F318DDA334E1ADC6F31EE04 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > No, what I'm describing is exactly related to the fragmentation problem= =2E >=20 > The IDP sends an assertion longer than 253 octets (quite probable). > The IDP knows which fragment will be dropped/reordered/whatever by the > proxy. > The IDP constructs an assertion such that the assertion will be > interpreted as a different attribute. > The IDP is authorized to send any assertion, but is not authorized to > send other attributes. > Thus, the IDP exceeds its authorization. Ah, thanks for giving this enlightening example :-) My gut reaction would be: if the IdP is not authorised to to send a particular attribute, as a receiver of RADIUS messages from that IdP, I would enforce this with some filtering policy. Attribute filters for incoming packets are quite commonly used e.g. in eduroam (strip out VLAN assignments coming from the IdP). This is again not directly related to fragmentation: the non-aware proxy will detect presence of an unauthorized attribute, and strip it. It does neither know nor care whether the originator constructed it "just like that" or whether it used a trick to send a non-first fragment that looked like a valid attribute. > All this of course depends on Peter coming back with an explanation > about how this is possible. That's true :-) Stefan > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig5F318DDA334E1ADC6F31EE04 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBptQcACgkQ+jm90f8eFWY0zgCcDN0JIiGVTgMSjjQsllra75Uq FSsAn1eAiDMtgi4pQlvtYXNoTzwXm5Os =t8PR -----END PGP SIGNATURE----- --------------enig5F318DDA334E1ADC6F31EE04-- From hartmans@painless-security.com Mon Oct 1 08:57:46 2012 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 2900511E8143 for ; Mon, 1 Oct 2012 08:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.379 X-Spam-Level: **** X-Spam-Status: No, score=4.379 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv-qMkKdVHD8 for ; Mon, 1 Oct 2012 08:57:45 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id F255211E8117 for ; Mon, 1 Oct 2012 08:57:44 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F31DB20289; Mon, 1 Oct 2012 11:57:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 254D9414A; Mon, 1 Oct 2012 11:57:39 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <5069B111.7040309@restena.lu> <5069B507.20607@restena.lu> Date: Mon, 01 Oct 2012 11:57:39 -0400 In-Reply-To: <5069B507.20607@restena.lu> (Stefan Winter's message of "Mon, 01 Oct 2012 17:21:43 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 15:57:46 -0000 >>>>> "Stefan" == Stefan Winter writes: Stefan> Hi, >> No, what I'm describing is exactly related to the fragmentation >> problem. >> >> The IDP sends an assertion longer than 253 octets (quite >> probable). The IDP knows which fragment will be >> dropped/reordered/whatever by the proxy. The IDP constructs an >> assertion such that the assertion will be interpreted as a >> different attribute. The IDP is authorized to send any >> assertion, but is not authorized to send other attributes. Thus, >> the IDP exceeds its authorization. Stefan> Ah, thanks for giving this enlightening example :-) Stefan> My gut reaction would be: if the IdP is not authorised to to Stefan> send a particular attribute, as a receiver of RADIUS Stefan> messages from that IdP, I would enforce this with some Stefan> filtering policy. Attribute filters for incoming packets are Stefan> quite commonly used e.g. in eduroam (strip out VLAN Stefan> assignments coming from the IdP). So, see. The RADIUS server is permitted to send the attribute. The IDP is not. A proxy cannot distinguish IDPs maliciously taking advantage of the encapsulation mechanism from servers inserting an attribute. So, no, I think filtering is an entirely inappropriate approach to fixing a bug in the encapsulation mechanism. From peterd@iea-software.com Mon Oct 1 09:46:22 2012 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 1EF951F0D0A for ; Mon, 1 Oct 2012 09:46:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffpV-mj2a1tM for ; Mon, 1 Oct 2012 09:46:21 -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 3FD9C1F0CCD for ; Mon, 1 Oct 2012 09:46:20 -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, 1 Oct 2012 09:47:59 -0700 Date: Mon, 1 Oct 2012 09:46:20 -0700 (Pacific Daylight Time) From: Peter Deacon To: Benoit Claise In-Reply-To: <5066FE87.6040309@cisco.com> Message-ID: References: <5066FE87.6040309@cisco.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "radext@ietf.org" , "Sanchez, Mauricio \(HP Networking\)" Subject: Re: [radext] new charter proposal 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, 01 Oct 2012 16:46:22 -0000 On Sat, 29 Sep 2012, Benoit Claise wrote: > Since we also discussed this new charter during the IETF meeting, I'll take the lack of replies as agreement. > However, I have a concern regarding the RADIUS Accounting Extensions for Traffic Statistics, for two reasons: > 1. there are two competing proposals, tactical approach vs. flexible > approach, as mentioned in the meeting minutes. And there is ongoing > discussion on the mailing regarding the direction to take. > of which To finally end up with the IPFIX flexibility, i.e. a template > based mechanism, based on any selection of all IPFIX IANA IEs I would settle for some kind of standard Class attribute in RADIUS authorization message able to find its way into a flow field in flows exported by NAS and just use a collector. Correlating addresses to sessions with aggregation delays and dynamically assigned addresses stink. Having something you can key off and always sliced on at least "Class" boundaries regardless of aggregation scheme would be awesome. > 2. If we go for the flexible approach, where do we stop in terms of > flexibility? Should the URN in WInter's draft contain: then ipv4 versus > ipv6, then all the DSCP values, then the next hop, then AS-path ... All Was thinking the other day of using the opaque labels concept as a bridge to correlate RADIUS accounting counters with filters defined during authorization and or OOB. Not saying I am for or against this just an idea. For example I need IPv6 flows I send a message during authorization saying please send me IPv6 -- and by the way use label 'MyIPv6' during accounting to provide this data. In accounting I would see a TLV with label 'MyIPv6' containing my byte and packet counts. I know what 'MyIPv6' means because this was defined during authorization using some undefined syntax?? A few points I think is important about this scheme and generally: You don't have to answer the complexity question up front. New filter syntaxes can be defined at any time for specific or general tasks without effecting the accounting portion. Could be as simple as filter defined in NAS OOB from RADIUS requiring no authorization attributes. It could be a complex IP filter defined via RADIUS authorization. It could be a complex filter defined in NAS. Accounting message size remains fixed regardless of complexity of a filter defined during RADIUS authorization. As mentioned before I still think that any sufficiently complex definition requires explanation to be useful to an accounting system. It is not enough simply to punt for example a DSCP option and expect the accounting system to understand what it means especially if it has only local significance per NAS or admin domain. If it was set via authorization the context to understand intention is available to accounting. If it is set OOB and you just get the DSCP option then potentially necessary context is lost. Other thoughts.. I don't see value in schemes where a ton of detailed data is transmitted for example flows between source and destination addresses. Better off using netflow if you want to do that. If I want data via AAA I only want to track a few things.. anything requiring a template cache is likely too much. regards, Peter From aland@deployingradius.com Mon Oct 1 09:54:39 2012 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 58B561F0D31 for ; Mon, 1 Oct 2012 09:54:39 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2RIeihMH8mN for ; Mon, 1 Oct 2012 09:54:38 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id C07331F0CCD for ; Mon, 1 Oct 2012 09:54:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 1593C2240D01; Mon, 1 Oct 2012 18:54:36 +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 MKZuuvTcC11D; Mon, 1 Oct 2012 18:54:35 +0200 (CEST) Received: from Thor.local (pas38-7-83-153-93-21.fbx.proxad.net [83.153.93.21]) by power.freeradius.org (Postfix) with ESMTPSA id 91DF62240797; Mon, 1 Oct 2012 18:54:35 +0200 (CEST) Message-ID: <5069CAD4.5010702@deployingradius.com> Date: Mon, 01 Oct 2012 18:54:44 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <5066FE87.6040309@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Benoit Claise , "radext@ietf.org" , "Sanchez, Mauricio \(HP Networking\)" Subject: Re: [radext] new charter proposal 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, 01 Oct 2012 16:54:39 -0000 Peter Deacon wrote: > Correlating addresses to sessions with aggregation delays and > dynamically assigned addresses stink. Having something you can key off > and always sliced on at least "Class" boundaries regardless of > aggregation scheme would be awesome. I agree. IPFIX supports a 64-bit flowID. That would seem to work here. > Other thoughts.. I don't see value in schemes where a ton of detailed > data is transmitted for example flows between source and destination > addresses. Better off using netflow if you want to do that. If I want > data via AAA I only want to track a few things.. anything requiring a > template cache is likely too much. That is a good point. I think there is getting to be more overlap between netflow and fine-grained AAA accounting. However, people have RADIUS proxy systems in place. They don't have much similar for netflow. Alan DeKok. From peterd@iea-software.com Mon Oct 1 10:49:12 2012 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 875751F0D17 for ; Mon, 1 Oct 2012 10:49:12 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWlnSmgjQbaJ for ; Mon, 1 Oct 2012 10:49:12 -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 E9EA61F0CCD for ; Mon, 1 Oct 2012 10:49:11 -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, 1 Oct 2012 10:50:59 -0700 Date: Mon, 1 Oct 2012 10:49:11 -0700 (Pacific Daylight Time) From: Peter Deacon To: Sam Hartman In-Reply-To: Message-ID: References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> <50698410.1050502@restena.lu> <50698611.5070000@deployingradius.com> <506992F4.3010701@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: Stefan Winter , "radext@ietf.org" , Alan DeKok Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 17:49:12 -0000 On Mon, 1 Oct 2012, Sam Hartman wrote: > Alan> But re-ordering attributes *is* forbidden under current > Alan> RFCS. > OK, then I'm confused. > Peter, can you try and explain your issue more clearly? Forwarding text and recommendation removal in RFC 2865 only. Does not apply to 2138 and 2058. RFC 2138 3. "Many Attributes may have multiple instances, in such a case the order of Attributes of the same Type SHOULD be preserved." Injection can cause same problems such as applying authorization from separate AAA while forwarding. regards, Peter From aland@deployingradius.com Mon Oct 1 13:47:43 2012 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 3E4011F0CD6 for ; Mon, 1 Oct 2012 13:47: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuHLk1UfgZdh for ; Mon, 1 Oct 2012 13:47:42 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50E771F040A for ; Mon, 1 Oct 2012 13:47:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 725442240D01; Mon, 1 Oct 2012 22:46:48 +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 5ZMvqfaZc5hk; Mon, 1 Oct 2012 22:46:46 +0200 (CEST) Received: from Thor.local (pas38-7-83-153-93-21.fbx.proxad.net [83.153.93.21]) by power.freeradius.org (Postfix) with ESMTPSA id 588B82240797; Mon, 1 Oct 2012 22:46:46 +0200 (CEST) Message-ID: <506A013F.5020701@deployingradius.com> Date: Mon, 01 Oct 2012 22:46:55 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> <50698410.1050502@restena.lu> <50698611.5070000@deployingradius.com> <506992F4.3010701@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , "radext@ietf.org" , Stefan Winter Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 20:47:43 -0000 Peter Deacon wrote: > Forwarding text and recommendation removal in RFC 2865 only. Does not > apply to 2138 and 2058. Uh... 2865 obseletes 2138, which in turn obseletes 2058. This is how the RFC process works. And 2865 is 12 years old. Anyone *not* implementing it deserves what they get. > RFC 2138 3. "Many Attributes may have multiple instances, in such a case > the order of Attributes of the same Type SHOULD be preserved." > > Injection can cause same problems such as applying authorization from > separate AAA while forwarding. So... a system which *doesn't* implement an attribute injects it into a packet? Is that right? Alan DeKok. From hartmans@painless-security.com Mon Oct 1 14:27:01 2012 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 23B841F0D5F for ; Mon, 1 Oct 2012 14:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.376 X-Spam-Level: **** X-Spam-Status: No, score=4.376 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlmHnaDWHIXj for ; Mon, 1 Oct 2012 14:27:00 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id A5DA71F040A for ; Mon, 1 Oct 2012 14:27:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D8D9120289; Mon, 1 Oct 2012 17:26:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B4A8B414A; Mon, 1 Oct 2012 17:26:54 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <5067EE7A.2090201@deployingradius.com> <50696649.5050001@restena.lu> <50696897.9000600@deployingradius.com> <50698410.1050502@restena.lu> <50698611.5070000@deployingradius.com> <506992F4.3010701@deployingradius.com> <506A013F.5020701@deployingradius.com> Date: Mon, 01 Oct 2012 17:26:54 -0400 In-Reply-To: <506A013F.5020701@deployingradius.com> (Alan DeKok's message of "Mon, 01 Oct 2012 22:46:55 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Stefan Winter , Peter Deacon , "radext@ietf.org" Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 01 Oct 2012 21:27:01 -0000 At this point I'm not requesting any changes with regard to this issue. Thanks for a discussion that helped me reach a conclusion. From peterd@iea-software.com Mon Oct 1 19:34:19 2012 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 4DC781F0D5B for ; Mon, 1 Oct 2012 19:34:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EahUhrLQSFCa for ; Mon, 1 Oct 2012 19:34:18 -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 45C5E1F0D44 for ; Mon, 1 Oct 2012 19:34:15 -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, 1 Oct 2012 19:30:30 -0700 Date: Mon, 1 Oct 2012 19:34:14 -0700 (Pacific Daylight Time) From: Peter Deacon To: Emile van Bergen In-Reply-To: <20121001233725.GF1697@omap> Message-ID: References: <5067EE7A.2090201@deployingradius.com> <20121001233725.GF1697@omap> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Sam Hartman , radext@ietf.org, jouni korhonen , Alan DeKok Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 02 Oct 2012 02:34:19 -0000 On Tue, 2 Oct 2012, Emile van Bergen wrote: > I've long gone into lurking mode, I can't resist now: that type of proxy > would incidentially be quite incapable of proxying any real world EAP > type. > Also note that RFC 3579 doesn't list incorrect interpretations due to > reordered EAP-Message attributes in its security considerations. I don't want to drag on a conversation that is obviously going nowhere fast so this will be my last comment on the subject. I previously discussed the issues with EAP and why it is different from long attributes. Obviously EAP and long attrs share a central concept in common. There are three differences I believe are important to consider: 1. Long attributes may also be used for authorization and accounting. EAP is with trivial exception authentication only. Long attributes will be subject to all kinds of contorted code paths simple EAP forwarding will never see. 2. No more than a single EAP conversation is allowed per packet. Multiple long attributes are allowed per packet. This raises possibilities for failures which do not apply to EAP. (You don't see a 'More' flag at the EAP-Message attribute level) I went thru this previously in detail if you want more information check the list archive or email me privately. 3. If you inject/mangle order of attributes of EAP end result is virtually guaranteed to be authentication failure. This is a failure mode I would happily accept if it were possible with long attributes. In fact this is all I seek...Parity with EAP behavior!!!! Should something happen I just want to make sure it gets detected and allow the whole transaction to go down in flames. We can't make this assumption with long attributes because we have no idea of any sort how they will be used. I have said previously no attempt should be made to reorder attributes if they are sent out of order even if sequence numbers were applied and you could safely do it. My goal has only been to detect things which scare me more than authentication failure.. corruption and small cracks left open some clever individual would be able to manipulate. > A widely used RADIUS application such as EAP should provide more than > sufficient precedent for a concatenation-based solution /without/ > additional facilities like sequence numbers. > The RADIUS data structure is quite elegant if you can see it as a named > array of of ordered lists. If you let go of the idea that attributes of > the same type are ordered, a lot of what you can build on top sudenly > becomes a whole lot uglier. (Filter rules -- EAP -- Extended attribute > encapsulation, to name a few recent hot topics). > The behaviour of the current population of deployed RADIUS servers > doesn't seem to warrant that at all, in my humble opinion. My issue is a matter of perspective and a matter of degree. We must all look to our experience and knowledge to make a value judgment and here I agree with most sentiments which have been expressed. Yet I also believe it prudent to acknowledge our own lack of visibility and error on the side of caution. With seemingly small possibility of a problem, potentially scary effect and something trivial which can be done about it without side effects then why not do it? If the sequence solution is deemed too hard perhaps Alan's idea for a start bit would clear out important problems esp with regards to VSAs. http://en.wikipedia.org/wiki/Robustness_principle regards, Peter From aland@deployingradius.com Tue Oct 2 00:01:09 2012 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 64F7D21F8B20 for ; Tue, 2 Oct 2012 00:01:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E18z2U+2kjlZ for ; Tue, 2 Oct 2012 00:01:08 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id C37DE21F8AFE for ; Tue, 2 Oct 2012 00:01:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 2EDBB2240E49; Tue, 2 Oct 2012 09:01: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 N-IuMvczhaTc; Tue, 2 Oct 2012 09:01:03 +0200 (CEST) Received: from Thor.local (pas38-7-83-153-93-21.fbx.proxad.net [83.153.93.21]) by power.freeradius.org (Postfix) with ESMTPSA id AFEFF22406BD; Tue, 2 Oct 2012 09:01:03 +0200 (CEST) Message-ID: <506A913A.6040508@deployingradius.com> Date: Tue, 02 Oct 2012 09:01:14 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <5067EE7A.2090201@deployingradius.com> <20121001233725.GF1697@omap> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Emile van Bergen , radext@ietf.org, jouni korhonen , Sam Hartman Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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, 02 Oct 2012 07:01:09 -0000 Peter Deacon wrote: > 3. If you inject/mangle order of attributes of EAP end result is > virtually guaranteed to be authentication failure. The key word is "virtually". The attacks you describe for long attributes apply equally well to EAP. > With seemingly small possibility of a problem, potentially scary effect > and something trivial which can be done about it without side effects > then why not do it? If the sequence solution is deemed too hard perhaps > Alan's idea for a start bit would clear out important problems esp with > regards to VSAs. A start bit would allow systems to detect and prevent the attack you describe. I'm looking for a clear statement on this matter. Throwing up problems without a conclusion doesn't help us move forward. The consensus of the WG seems to be against any change to the spec. Can you make an unambiguous statement in favor (or against) the start bit idea? And also state whether or not you agree it would address your concerns? I'm OK with adding a start bit to the document. It is a minor change, and seems (to me) to completely protect against the attacks you describe. I believe that the attacks are due *solely* to misbehaving proxies, and that this issue has not been seen in practice. Yet I'm willing to make a change, because having a robust / secure protocol is a good thing. Alan DeKok. From leaf.y.yeh@huawei.com Mon Oct 8 00:59:58 2012 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 0F9F021F86D5 for ; Mon, 8 Oct 2012 00:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRXz-lEzu2F5 for ; Mon, 8 Oct 2012 00:59:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2B19021F84FA for ; Mon, 8 Oct 2012 00:59:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKJ89314; Mon, 08 Oct 2012 07:59:47 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 08:59:22 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 08:59:46 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.192]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Mon, 8 Oct 2012 15:58:55 +0800 From: Leaf yeh To: Peter Deacon , Benoit Claise Thread-Topic: [radext] new charter proposal Thread-Index: AQHNnkqSLsXE5SX/eUqt75JvZAcKlJekJd8AgArvfvA= Date: Mon, 8 Oct 2012 07:58:55 +0000 Message-ID: References: <5066FE87.6040309@cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "radext@ietf.org" , "Sanchez, Mauricio \(HP Networking\)" , "mohamed.boucadair@orange.com" Subject: Re: [radext] new charter proposal 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, 08 Oct 2012 07:59:58 -0000 Peter - As mentioned before I still think that any sufficiently complex def= inition=20 requires explanation to be useful to an accounting system. It is not=20 enough simply to punt for example a DSCP option and expect the accounting=20 system to understand what it means especially if it has only local=20 significance per NAS or admin domain. I regard DSCP-type is optional now, it might need more discussion. If opera= tors need it, it sounds closely to the SLA (gold, silver or bronze, and etc= ) of services, which is associated with billing or accounting.=20 But it seems to me the full DSCP codes looks naturally as the 'Enumerated I= nteger'. I meant it is easier to express it in 'integer'. :-) Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of= Peter Deacon Sent: Tuesday, October 02, 2012 12:46 AM To: Benoit Claise Cc: radext@ietf.org; Sanchez, Mauricio (HP Networking) Subject: Re: [radext] new charter proposal On Sat, 29 Sep 2012, Benoit Claise wrote: > Since we also discussed this new charter during the IETF meeting, I'll ta= ke the lack of replies as agreement. > However, I have a concern regarding the RADIUS Accounting Extensions for = Traffic Statistics, for two reasons: > 1. there are two competing proposals, tactical approach vs. flexible=20 > approach, as mentioned in the meeting minutes. And there is ongoing=20 > discussion on the mailing regarding the direction to take. > of which To finally end up with the IPFIX flexibility, i.e. a template=20 > based mechanism, based on any selection of all IPFIX IANA IEs I would settle for some kind of standard Class attribute in RADIUS=20 authorization message able to find its way into a flow field in flows=20 exported by NAS and just use a collector. Correlating addresses to sessions with aggregation delays and dynamically=20 assigned addresses stink. Having something you can key off and always=20 sliced on at least "Class" boundaries regardless of aggregation scheme=20 would be awesome. > 2. If we go for the flexible approach, where do we stop in terms of=20 > flexibility? Should the URN in WInter's draft contain: then ipv4 versus=20 > ipv6, then all the DSCP values, then the next hop, then AS-path ... All Was thinking the other day of using the opaque labels concept as a bridge=20 to correlate RADIUS accounting counters with filters defined during=20 authorization and or OOB. Not saying I am for or against this just an=20 idea. For example I need IPv6 flows I send a message during authorization saying= =20 please send me IPv6 -- and by the way use label 'MyIPv6' during accounting= =20 to provide this data. In accounting I would see a TLV with label 'MyIPv6' containing my byte and= =20 packet counts. I know what 'MyIPv6' means because this was defined during= =20 authorization using some undefined syntax?? A few points I think is important about this scheme and generally: You don't have to answer the complexity question up front. New filter=20 syntaxes can be defined at any time for specific or general tasks without=20 effecting the accounting portion. Could be as simple as filter defined in NAS OOB from RADIUS requiring no=20 authorization attributes. It could be a complex IP filter defined via RADIUS authorization. It could be a complex filter defined in NAS. Accounting message size remains fixed regardless of complexity of a filter= =20 defined during RADIUS authorization. As mentioned before I still think that any sufficiently complex definition= =20 requires explanation to be useful to an accounting system. It is not=20 enough simply to punt for example a DSCP option and expect the accounting=20 system to understand what it means especially if it has only local=20 significance per NAS or admin domain. If it was set via authorization the context to understand intention is=20 available to accounting. If it is set OOB and you just get the DSCP=20 option then potentially necessary context is lost. Other thoughts.. I don't see value in schemes where a ton of detailed data= =20 is transmitted for example flows between source and destination addresses.= =20 Better off using netflow if you want to do that. If I want data via AAA I= =20 only want to track a few things.. anything requiring a template cache is=20 likely too much. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Mon Oct 8 07:20:06 2012 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 1C8C521F8584 for ; Mon, 8 Oct 2012 07:20:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCyXpcvwQHvi for ; Mon, 8 Oct 2012 07:20:05 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41BE021F8570 for ; Mon, 8 Oct 2012 07:20:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 706F92240B9C; Mon, 8 Oct 2012 16:20:03 +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 UhfA7kujnD+y; Mon, 8 Oct 2012 16:20:03 +0200 (CEST) Received: from Thor.local (206-47-95-94.dsl.ncf.ca [206.47.95.94]) by power.freeradius.org (Postfix) with ESMTPSA id 88DDB22406F6; Mon, 8 Oct 2012 16:20:02 +0200 (CEST) Message-ID: <5072E130.1090901@deployingradius.com> Date: Mon, 08 Oct 2012 10:20:32 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "radext@ietf.org" , "Benoit Claise (bclaise)" Content-Type: multipart/mixed; boundary="------------000309030809040200040207" Subject: [radext] [Fwd: New Version Notification for draft-dekok-radius-ipfix-00.txt] 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, 08 Oct 2012 14:20:06 -0000 This is a multi-part message in MIME format. --------------000309030809040200040207 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Based on suggestions by Benoit and discussion with Stefan, I've submitted a new draft. It proposes to leverage IPFIX for complex RADIUS accounting. It doesn't replace Stefan's draft. It's another option. We'll have to see what the WG thinks of the various approaches. Alan DeKok. --------------000309030809040200040207 Content-Type: message/rfc822; name="New Version Notification for draft-dekok-radius-ipfix-00.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-dekok-radius-ipfix-00.txt"; filename*1=".eml" Return-Path: Received: from power.freeradius.org ([unix socket]) by power.freeradius.org (Cyrus v2.4.12-Debian-2.4.12-2) with LMTPA; Mon, 08 Oct 2012 16:11:52 +0200 X-Sieve: CMU Sieve 2.4 Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 123312240B9C for ; Mon, 8 Oct 2012 16:11:52 +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 ZBGTNIzNzNwg for ; Mon, 8 Oct 2012 16:11:51 +0200 (CEST) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=64.170.98.30; helo=mail.ietf.org; envelope-from=internet-drafts@ietf.org; receiver=aland@freeradius.org Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by power.freeradius.org (Postfix) with ESMTP id AC9BD224070E for ; Mon, 8 Oct 2012 16:11:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AE221F87CC; Mon, 8 Oct 2012 07:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGPrO78cIvmT; Mon, 8 Oct 2012 07:11:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527A111E8097; Mon, 8 Oct 2012 07:11:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: aland@freeradius.org Cc: stefan.winter@restena.lu Subject: New Version Notification for draft-dekok-radius-ipfix-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121008141150.10923.74234.idtracker@ietfa.amsl.com> Date: Mon, 08 Oct 2012 07:11:50 -0700 A new version of I-D, draft-dekok-radius-ipfix-00.txt has been successfully submitted by Alan DeKok and posted to the IETF repository. Filename: draft-dekok-radius-ipfix Revision: 00 Title: RADIUS accounting via IPFIX Creation date: 2012-10-08 WG ID: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-dekok-radius-ipf= ix-00.txt Status: http://datatracker.ietf.org/doc/draft-dekok-radius-ipfix Htmlized: http://tools.ietf.org/html/draft-dekok-radius-ipfix-00 Abstract: The Remote Authentication Dial In User Server (RADIUS) Protocol provides for a number of simple session-based metrics. There is a need to increase the number of metrics, and to add metrics for individual flows within a session. This document leverages IP Flow Information Export (IPFIX) to address both needs. = = The IETF Secretariat --------------000309030809040200040207-- From ghalwasi@cisco.com Mon Oct 8 19:34:25 2012 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 2140411E80BF for ; Mon, 8 Oct 2012 19:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.37 X-Spam-Level: X-Spam-Status: No, score=-10.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U68sHx5aRvRT for ; Mon, 8 Oct 2012 19:34:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6397611E809B for ; Mon, 8 Oct 2012 19:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2600; q=dns/txt; s=iport; t=1349750064; x=1350959664; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7zEnSniSJGW6+HfxU2ReRLnjcLfn8HI5wpqpQwLnpVI=; b=gYffXCXNrh9IvjuVyz0xItmy+aTGHF8p3TExwF0nC03336zR489/lvb8 t63rGM0fPigcP0g6JZrh51WVB1X0fPoPqmzxEJdXgcMzXPoca2Cmz+ojZ S2AnQgLSxzQ0pjddJJXTG7i1KrgB2LFBkfdasuDikigOSxtsrIyQ+rIL7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAAONc1CtJXG//2dsb2JhbABFhhG4JH2BCIIgAQEBBBIBEBFDAgwEAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBA4FCAEZh2MLmliNG4I7kDOBIYomhQEyYAOXAI0wgWmCYA2CFw X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="129554211" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 09 Oct 2012 02:34:22 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q992YM2V014052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 02:34:22 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.220]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 21:34:21 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "radext@ietf.org" Thread-Topic: New Version Notification for draft-halwasia-radext-capability-negotiation-01.txt Thread-Index: AQHNpVjsVH/69p0NNUadgsoMz+QF7ZewPhwA Date: Tue, 9 Oct 2012 02:34:20 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB1BD69590@xmb-aln-x06.cisco.com> References: <20121008132918.20468.37502.idtracker@ietfa.amsl.com> In-Reply-To: <20121008132918.20468.37502.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.77.155] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--29.094800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Manoj Kumar \(magoyal\)" , "Satyanarayana Danda \(sdanda\)" , "aland@deployingradius.com" Subject: [radext] FW: New Version Notification for draft-halwasia-radext-capability-negotiation-01.txt 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, 09 Oct 2012 02:34:25 -0000 SGkgVGVhbSwNCg0KV2UgaGF2ZSBwb3N0ZWQgYSBuZXcgSS5EIHdoaWNoIGlzIGRlZmluaW5nIGEg J0NhcGFiaWxpdHkgTmVnb3RpYXRpb24nIEZyYW1ld29yayBpbiBiZXR3ZWVuIFJBRElVUyBjbGll bnQgYW5kIHNlcnZlci4gV2UgdGhpbmsgdGhhdCB0aGlzIGlzIGEgdXNlZnVsIHdvcmsgYW5kIHNw ZWNpZmljYWxseSB3aXRoIHRoZSBsb3Qgb2YgZXh0ZW5zaW9ucyBpbiBSQURJVVMgcHJvdG9jb2wg KGFscmVhZHkgdW5kZXJ3YXkgYW5kIHByb3Bvc2VkIGluIGZ1dHVyZSkuDQogDQpXZSByZXF1ZXN0 IHdvcmtpbmcgZ3JvdXAgbWVtYmVycyB0byBraW5kbHkgcmV2aWV3IHRoaXMgZG9jdW1lbnQgYW5k IHByb3ZpZGUgY29tbWVudHMuICANCg0KUmVnYXJkcywNCkF1dGhvcihzKSAgICAgICA6IEFsYW4g RGVLb2sNCiAgICAgICAgICAgICAgICAgICAgICAgICBHYXVyYXYgSGFsd2FzaWENCiAgICAgICAg ICAgICAgICAgICAgICAgICBTYXR5YW5hcmF5YW5hIERhbmRhDQogICAgICAgICAgICAgICAgICAg ICAgICAgTWFub2ogS3VtYXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10g DQpTZW50OiBNb25kYXksIE9jdG9iZXIgMDgsIDIwMTIgNjo1OSBQTQ0KVG86IEdhdXJhdiBIYWx3 YXNpYSAoZ2hhbHdhc2kpDQpDYzogTWFub2ogS3VtYXIgKG1hZ295YWwpOyBTYXR5YW5hcmF5YW5h IERhbmRhIChzZGFuZGEpOyBhbGFuZEBkZXBsb3lpbmdyYWRpdXMuY29tDQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhbHdhc2lhLXJhZGV4dC1jYXBhYmlsaXR5 LW5lZ290aWF0aW9uLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1oYWx3 YXNpYS1yYWRleHQtY2FwYWJpbGl0eS1uZWdvdGlhdGlvbi0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgR2F1cmF2IEhhbHdhc2lhIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1oYWx3YXNpYS1yYWRleHQtY2FwYWJp bGl0eS1uZWdvdGlhdGlvbg0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgQ2FwYWJpbGl0eSBOZWdv dGlhdGlvbiBpbiBSQURJVVMNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTEwLTA4DQpXRyBJRDoJCSBJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTINClVSTDogICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaGFsd2FzaWEtcmFk ZXh0LWNhcGFiaWxpdHktbmVnb3RpYXRpb24tMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFsd2FzaWEtcmFkZXh0LWNhcGFiaWxp dHktbmVnb3RpYXRpb24NCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaGFsd2FzaWEtcmFkZXh0LWNhcGFiaWxpdHktbmVnb3RpYXRpb24tMDENCkRpZmY6 ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaGFsd2Fz aWEtcmFkZXh0LWNhcGFiaWxpdHktbmVnb3RpYXRpb24tMDENCg0KQWJzdHJhY3Q6DQogICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBwcm9jZWR1cmUgYW5kIG1lY2hhbmlzbSB0byBleGNoYW5nZSBh bmQNCiAgIG5lZ290aWF0ZSBjYXBhYmlsaXRpZXMgYmV0d2VlbiBSQURJVVMgY2xpZW50IGFuZCBS QURJVVMgc2VydmVyLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= From leaf.y.yeh@huawei.com Mon Oct 8 19:38:24 2012 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 A6E4B21F8487; Mon, 8 Oct 2012 19:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBIKVFZPHRSa; Mon, 8 Oct 2012 19:38:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3403D11E809B; Mon, 8 Oct 2012 19:38:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKK63389; Tue, 09 Oct 2012 02:38:21 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 9 Oct 2012 03:38:05 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 9 Oct 2012 03:38:17 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.192]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Tue, 9 Oct 2012 10:38:14 +0800 From: Leaf yeh To: "aland@deployingradius.com" , Bernard Aboba Thread-Topic: [Softwires] [Technical Errata Reported] RFC6519 (3372) Thread-Index: AQHNpVF09lcNwk9Xbke928JQybrftJewPERg Date: Tue, 9 Oct 2012 02:38:13 +0000 Message-ID: References: <20121008123051.F3455B1E003@rfc-editor.org> In-Reply-To: <20121008123051.F3455B1E003@rfc-editor.org> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" , "radext@ietf.org" Subject: Re: [radext] [Softwires] [Technical Errata Reported] RFC6519 (3372) 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, 09 Oct 2012 02:38:24 -0000 Could we update the description of 'service-type(6)=3DCall check' as follow= s,=20 '... typically based on the NAS-Port-Id(87), or Calling-Station-Id(31) attr= ibutes, etc. It is recommended that such Access-Requests use the value of N= AS-Port-Id or Calling-Station-Id as the value of the User-Name.' if we believe the *call* is not only associated with the telephone system? Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of RFC Errata System Sent: Monday, October 08, 2012 8:31 PM To: roberta.maglione@telecomitalia.it; adurand@juniper.net; rdroms.ietf@gma= il.com; brian@innovationslab.net; suresh.krishnan@ericsson.com; cuiyong@tsi= nghua.edu.cn Cc: softwires@ietf.org; rfc-editor@rfc-editor.org; aland@deployingradius.co= m Subject: [Softwires] [Technical Errata Reported] RFC6519 (3372) The following errata report has been submitted for RFC6519, "RADIUS Extensions for Dual-Stack Lite". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6519&eid=3D3372 -------------------------------------- Type: Technical Reported by: Alan DeKok Section: 3 Original Text ------------- In the scenario depicted in Figure 2, the Access-Request packet contains a Service-Type attribute with the value Authorize Only (17); thus, according to [RFC5080], the Access-Request packet MUST contain a State attribute. Corrected Text -------------- In the scenario depicted in Figure 2, the Access-Request packet contains a Service-Type attribute with the value Call-Check (10). Notes ----- The document references RFC 5080. However, the use of the State attribute = in this document is wrong. The text in RFC 5080 clearly says that State is= used to tie an "Authorize Only" request to a previous authentication. The= text requiring State in "Authorize Only" is surrounded by explanations des= cribing *why* it's required. The original text in RFC 6519 appears to say that adding State magically sa= tisfies the requirements of 5080. But it ignores all of the surrounding te= xt. The NAS can't simply invent a State attribute, to satisfy the requirement o= f 5080. It MUST get the State from a previous Access-Accept. Since there'= s no previous Access-Accept here, the use of Authorize-Only and State is wr= ong. RFC 2865 suggests the use of "Service-Type =3D Call Check" for this kind of= authorization checking: Call Check=20 Used by the NAS in an Access-Request packet to indicate that a call is being received and that the RADIUS server should send back an Access-Accept to answer the call, or an Access-Reject to not accept the call, typically based on the Called-Station-Id or Calling-Station-Id attributes. It is recommended that such Access-Requests use the value of Calling-Station-Id as the value of the User-Name Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC6519 (draft-ietf-softwire-dslite-radius-ext-07) -------------------------------------- Title : RADIUS Extensions for Dual-Stack Lite Publication Date : February 2012 Author(s) : R. Maglione, A. Durand Category : PROPOSED STANDARD Source : Softwires Area : Internet Stream : IETF Verifying Party : IESG _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From jouni.nospam@gmail.com Thu Oct 11 01:09:45 2012 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 C653121F8513 for ; Thu, 11 Oct 2012 01:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEzXgXiLE+F3 for ; Thu, 11 Oct 2012 01:09:45 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2330721F84CE for ; Thu, 11 Oct 2012 01:09:44 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so6639062wib.13 for ; Thu, 11 Oct 2012 01:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=4VyRkhz9hIGE8x0iB4JklfXtEkNW0fBf9p7RP2MDqps=; b=MktJZx4cCFmcQ8FziAzPt75al0GuQbqNCzFDei/TSWmZ11KIydYM8MqpHPl7lL8ADr jtA6ypz1/gBYrm3YklyPRFcNb6Oy8aGdCjd/Uk9yKjKul6L643cYM/7SzoYYh5PzIHW4 ZWBVMxodL7cQaylFaSWZM38vXROu9Z1sziTVJwAEXNMlM8UHT3Hb/rcQr2ygB3nXEiX7 PiyAib3gR+EfGVyWTZmiSGxlHT3QPozY52qBcvthhCOVNJ/irlY/UxDo/I1BC1CQAur/ JfmPU2tuJk3p95iIKJWNY65tkeeGOLD+nJan9jURmrOiRBKNS+/hzJYJpiOBQURFkxMi TyWw== Received: by 10.216.200.150 with SMTP id z22mr51954wen.97.1349942984286; Thu, 11 Oct 2012 01:09:44 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id eq2sm7405741wib.1.2012.10.11.01.09.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Oct 2012 01:09:43 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Oct 2012 11:09:40 +0300 Message-Id: To: radext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: radext-chairs@tools.ietf.org Subject: [radext] RADEXT WG meeting in Atlanta 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: Thu, 11 Oct 2012 08:09:45 -0000 Folks, Different from the tradition RADEXT is not going to meet on the last = slot on Friday ;) We have a 1.5h slot on TUESDAY, November 6, 2012 between 1520-1650 = (still tentative). If you feel like presenting something, send the co-chair a mail with the topic, estimated airtime and why you think it needs to get a slot. - Jouni & Mauricio= From aland@deployingradius.com Thu Oct 11 05:40:47 2012 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 70C0421F86F0 for ; Thu, 11 Oct 2012 05:40:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZFKFcRLHIMR for ; Thu, 11 Oct 2012 05:40:47 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id D0C2C21F86A5 for ; Thu, 11 Oct 2012 05:40:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A159B2240C30; Thu, 11 Oct 2012 14:39:51 +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 bllrrpNYbv7n; Thu, 11 Oct 2012 14:39:51 +0200 (CEST) Received: from Thor.local (206-47-95-94.dsl.ncf.ca [206.47.95.94]) by power.freeradius.org (Postfix) with ESMTPSA id 57B4E224070E; Thu, 11 Oct 2012 14:39:50 +0200 (CEST) Message-ID: <5076BE3C.6090203@deployingradius.com> Date: Thu, 11 Oct 2012 08:40:28 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <5067EE7A.2090201@deployingradius.com> <20121001233725.GF1697@omap> <506A913A.6040508@deployingradius.com> In-Reply-To: <506A913A.6040508@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Emile van Bergen , radext@ietf.org, jouni korhonen , Sam Hartman Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-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: Thu, 11 Oct 2012 12:40:47 -0000 Alan DeKok wrote: > I'm looking for a clear statement on this matter. Throwing up > problems without a conclusion doesn't help us move forward. The > consensus of the WG seems to be against any change to the spec. There has been no response to that query. There is therefore no reason to make any change to the document. As has been noted on this list, the alleged attack vector has not been seen for EAP, even with proxies that are EAP unaware. Alan DeKok. From jouni.nospam@gmail.com Mon Oct 15 00:58:44 2012 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 933F921F848F for ; Mon, 15 Oct 2012 00:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2IJtOxc6aS8 for ; Mon, 15 Oct 2012 00:58:44 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D0B7821F845C for ; Mon, 15 Oct 2012 00:58:43 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so2973623eek.31 for ; Mon, 15 Oct 2012 00:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=vzUJ+bKBxvLTjOOAsQl/3x/aVoH3w963hrW8CsOWfwg=; b=xkOkwsVUUSVVqTywzLzp5S+iagLuoDTLvhogdN1kiKuutUvuupJnx2p4/t6kE6OV16 gbedYg5naYp2Jbj/7X5XoKZQGm801gXdKY7hZmkjXgYK8zk43ERYeOt9EqJf6jDEzH9o 0g5VqW30RVI/cvmCdBDNdiaDSqkmP46RChwJDGYV36JDcOLH5YRQp7AU796g+nGA4oRc ZHtG+lytTYA1d89or7sajSMcNGgvUrU3jHgP5zvQYMVJvgmfB2s1pD40OKf1ToCWifTz DJqqPRzhmqp38Ro7gaKQaRLFAIxHOXsj27V562uhZqpD49vH5aPhfai9YNYOJ6TUa50E z5sg== Received: by 10.14.215.69 with SMTP id d45mr14482174eep.16.1350287922994; Mon, 15 Oct 2012 00:58:42 -0700 (PDT) Received: from [10.255.134.20] ([194.251.119.201]) by mx.google.com with ESMTPS id v3sm23608489een.1.2012.10.15.00.58.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Oct 2012 00:58:36 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 15 Oct 2012 10:58:34 +0300 Message-Id: To: radext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Benoit Claise , radext-chairs@tools.ietf.org Subject: [radext] WGLC ended for draft-ietf-radext-radius-extensions-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, 15 Oct 2012 07:58:44 -0000 Folks, This draft was placed into two weeks WGLC and that has now passed: http://www.ietf.org/mail-archive/web/radext/current/msg07799.html I conclude we have had enough discussion to move the document forward as it is now. Thanks. - Jouni & Mauricio RADEXT co-chairs From klaas@wierenga.net Mon Oct 15 04:15:25 2012 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 6034021F86C3 for ; Mon, 15 Oct 2012 04:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TidMwwjsq025 for ; Mon, 15 Oct 2012 04:15:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 26CE121F86B6 for ; Mon, 15 Oct 2012 04:15:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJPve1CtJXG9/2dsb2JhbABFv3eBCIIgAQEBAwESASc9BwscAQIBAi9JBAIIBhMJGYdcBgudUp9Bi1mFXWADlwGNMIFrgm8 X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="131620385" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 15 Oct 2012 11:15:22 +0000 Received: from rtp-vpn6-1164.cisco.com (rtp-vpn6-1164.cisco.com [10.82.252.144]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9FBEJ4e030887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 15 Oct 2012 11:15:22 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Oct 2012 13:15:21 +0200 References: <20121015102423.29339.12997.idtracker@ietfa.amsl.com> To: "radext@ietf.org" Message-Id: <2CF68554-EC3F-4C39-933D-18952186B578@wierenga.net> Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Subject: [radext] Fwd: New Version Notification for draft-wierenga-ietf-eduroam-00.txt 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, 15 Oct 2012 11:15:25 -0000 FYI Begin forwarded message: > From: > Subject: New Version Notification for = draft-wierenga-ietf-eduroam-00.txt > Date: October 15, 2012 12:24:23 PM GMT+02:00 > To: > Cc: , >=20 >=20 > A new version of I-D, draft-wierenga-ietf-eduroam-00.txt > has been successfully submitted by Klaas Wierenga and posted to the > IETF repository. >=20 > Filename: draft-wierenga-ietf-eduroam > Revision: 00 > Title: The eduroam architecture for network roaming > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 31 > URL: = http://www.ietf.org/internet-drafts/draft-wierenga-ietf-eduroam-00.txt > Status: = http://datatracker.ietf.org/doc/draft-wierenga-ietf-eduroam > Htmlized: = http://tools.ietf.org/html/draft-wierenga-ietf-eduroam-00 >=20 >=20 > Abstract: > This document describes the architecture of the eduroam service for > federated (wireless) network access in academia. The combination of > 802.1X, EAP and RADIUS that is used in eduroam provides a secure, > scalable and deployable service for roaming network access. The > successful deployment of eduroam over the last decade in the > educational sector may serve as an example for other sectors, hence > this document. In particular the initial architectural and = standards > choices and the changes that were prompted by operational experience > are highlighted. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From trac+radext@trac.tools.ietf.org Wed Oct 17 00:27:48 2012 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 90F7321F8744 for ; Wed, 17 Oct 2012 00:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.796 X-Spam-Level: X-Spam-Status: No, score=-100.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, LONGWORDS=1.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O3DrbVUmInO for ; Wed, 17 Oct 2012 00:27:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id DFF9C21F8747 for ; Wed, 17 Oct 2012 00:27:47 -0700 (PDT) Received: from localhost ([127.0.0.1]:46490 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TOO2M-0006qA-3L; Wed, 17 Oct 2012 09:27:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-radext-radius-extensions@tools.ietf.org, peterd@iea-software.com X-Trac-Project: radext Date: Wed, 17 Oct 2012 07:27:30 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/129 Message-ID: <064.e74aafa86b70590c821aa1d5f8de333f@trac.tools.ietf.org> X-Trac-Ticket-ID: 129 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-extensions@tools.ietf.org, peterd@iea-software.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@networkradius.com, avi@bridgewatersystems.com Resent-Message-Id: <20121017072747.DFF9C21F8747@ietfa.amsl.com> Resent-Date: Wed, 17 Oct 2012 00:27:47 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #129: 9.2 nit inconsistent long extended type vsa example X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 07:27:48 -0000 #129: 9.2 nit inconsistent long extended type vsa example Wire example does not match output. One too many a's and different ending characters. Recommend following: {{{ 245.26.1.6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcbcccccccccccccccccccccc cccccccccccccc -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 17 1a 00 cb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc }}} -- -------------------------+------------------------------------------------- Reporter: peterd@… | Owner: draft-ietf-radext-radius- Type: defect | extensions@… Priority: trivial | Status: new Component: radius- | Milestone: extensions | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: radext From internet-drafts@ietf.org Thu Oct 18 06:33:02 2012 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 74A4821F87A3; Thu, 18 Oct 2012 06:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9tkO8rv9Xkf; Thu, 18 Oct 2012 06:33:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B163421F87A5; Thu, 18 Oct 2012 06:33:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121018133301.1166.98061.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2012 06:33:01 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-12.txt 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: Thu, 18 Oct 2012 13:33:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : RADIUS attributes for IPv6 Access Networks Author(s) : Cisco Systems Huawei USA Network Zen Filename : draft-ietf-radext-ipv6-access-12.txt Pages : 12 Date : 2012-10-18 Abstract: This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Oct 19 08:35:11 2012 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 C9EC021F8743; Fri, 19 Oct 2012 08:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0vg786YaZ-X; Fri, 19 Oct 2012 08:35:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C02E21F85FE; Fri, 19 Oct 2012 08:35:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019153511.22589.49621.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 08:35:11 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-13.txt 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: Fri, 19 Oct 2012 15:35:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : RADIUS attributes for IPv6 Access Networks Author(s) : Cisco Systems Huawei USA Network Zen Filename : draft-ietf-radext-ipv6-access-13.txt Pages : 12 Date : 2012-10-19 Abstract: This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trac+radext@trac.tools.ietf.org Sun Oct 21 19:08:39 2012 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 6433521F8AD3 for ; Sun, 21 Oct 2012 19:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.698 X-Spam-Level: X-Spam-Status: No, score=-101.698 tagged_above=-999 required=5 tests=[AWL=0.902, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnVIavDA2CJc for ; Sun, 21 Oct 2012 19:08:38 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id B337A21F8A94 for ; Sun, 21 Oct 2012 19:08:38 -0700 (PDT) Received: from localhost ([127.0.0.1]:52018 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TQ7R8-0002fy-46; Mon, 22 Oct 2012 04:08:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bernard_aboba@hotmail.com, Bernard_Aboba@hotmail.com X-Trac-Project: radext Date: Mon, 22 Oct 2012 02:08:14 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/109#comment:3 Message-ID: <074.5ac011411db3d91176612c8fb218c7cd@trac.tools.ietf.org> References: <059.c3a1bc8c14e150831b18a5e69f571d5e@trac.tools.ietf.org> X-Trac-Ticket-ID: 109 In-Reply-To: <059.c3a1bc8c14e150831b18a5e69f571d5e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, Bernard_Aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: Re: [radext] #109: Additional IEEE 802.11 Attributes X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 02:08:39 -0000 #109: Additional IEEE 802.11 Attributes Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: The proposed resolution provides the following changes to the text of Section 2.14: 2.14. WLAN-Reason-Code Description The WLAN-Reason-Code Attribute contains information on the reason why a station has been dissaciated or de-authenticated. This can occur due to policy or for reasons related to the user's subscription. A WLAN-Reason-Code Attribute MAY be included within an Access- Reject or Disconnect-Request packet. Upon receipt of an Access- Reject or Disconnect-Request packet containing a WLAN-Reason-Code Attribute, the WLAN-Reason-Code value is copied by the Access Point into the Reason code field of a Disassociation or Deauthentication frame (see clause 8.3.3.4 and 8.3.3.12 respectively in [IEEE- 802.11]), which is subsequently transmitted to the station. In order to provide information within an Accounting-Request on why a station has been disassociated or de- authenticated, the Acct-Termination-Cause Attribute is used, rather than the WLAN-Reason-Code Attribute. A summary of the WLAN-Reason-Code Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code TBD13 Length 4 Value The Value field is a 32-bit unsigned integer drawn from Table 8-36 in clause 8.4.1.7 of [IEEE-802.11]. The following Reason codes for public Wi-Fi access networks (and the corresponding additional values of the Acct-Terminate-Cause Attribute) were added by the IEEE 802.11u-2011 amendment: Reason Acct- Description Code Terminate- Value Cause 27 24 Disassociated because session terminated by service provider request 28 25 Disassociated because of lack of service provider roaming agreement 29 26 Requested service rejected because of service provider cipher suite or AKM requirement 30 27 Requested service not authorized in this location -- -----------------------------+------------------------------ Reporter: jsalowey@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+------------------------------ Ticket URL: radext From internet-drafts@ietf.org Sun Oct 21 19:13:19 2012 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 A754321F8AD2; Sun, 21 Oct 2012 19:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkEdjctUPMOg; Sun, 21 Oct 2012 19:13:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A65621F8AD4; Sun, 21 Oct 2012 19:13:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022021319.18563.6386.idtracker@ietfa.amsl.com> Date: Sun, 21 Oct 2012 19:13:19 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ieee802ext-03.txt 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, 22 Oct 2012 02:13:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : RADIUS Attributes for IEEE 802 Networks Author(s) : Bernard Aboba Jouni Malinen Paul Congdon Joseph Salowey Mark Jones Filename : draft-ietf-radext-ieee802ext-03.txt Pages : 28 Date : 2012-10-21 Abstract: RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks, as well as clarifications on the usage of the EAP- Key-Name attribute, updating RFC 4072. The attributes defined in this document are usable both within RADIUS and Diameter. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ieee802ext There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-ieee802ext-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ieee802ext-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leaf.y.yeh@huawei.com Sun Oct 21 19:53:41 2012 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 B277021F8BBE for ; Sun, 21 Oct 2012 19:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBXwm0y05YPy for ; Sun, 21 Oct 2012 19:53:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFFF21F8B07 for ; Sun, 21 Oct 2012 19:53:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKU85880; Mon, 22 Oct 2012 02:53:37 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 22 Oct 2012 03:53:33 +0100 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 22 Oct 2012 03:53:36 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Mon, 22 Oct 2012 10:53:31 +0800 From: Leaf yeh To: jouni korhonen , "radext@ietf.org" Thread-Topic: [radext] RADEXT WG meeting in Atlanta Thread-Index: AQHNp4fM8mYapky5S0W7zjRHDpX5WZfErmjw Date: Mon, 22 Oct 2012 02:53:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "radext-chairs@tools.ietf.org" Subject: Re: [radext] RADEXT WG meeting in Atlanta 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, 22 Oct 2012 02:53:41 -0000 Dear chairs and folks, I will not appear in Atlanta for IETF84, but the contribution (http://datat= racker.ietf.org/doc/draft-yeh-radext-ext-traffic-statistics/) has already b= een updated on the web of RADEXT for your further valuable comments. 'Note: This document tries to narrow the scope of the solution space just to meet the requirements explicitly expressed by the industry without defining new RADIUS messages or introducing a new namespace for the additional interoperability.' (quoted from the section of Intro= duction.) Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of= jouni korhonen Sent: Thursday, October 11, 2012 4:10 PM To: radext@ietf.org Cc: radext-chairs@tools.ietf.org Subject: [radext] RADEXT WG meeting in Atlanta Folks, Different from the tradition RADEXT is not going to meet on the last slot o= n Friday ;) We have a 1.5h slot on TUESDAY, November 6, 2012 between 1520-1650 (still t= entative). If you feel like presenting something, send the co-chair a mail with the topic, estimated airtime and why you think it needs to get a slot. - Jouni & Mauricio _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From alper.yegin@yegin.org Mon Oct 22 03:07:09 2012 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 F3E6021F8B03; Mon, 22 Oct 2012 03:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+Y3biSGU7iN; Mon, 22 Oct 2012 03:07:08 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7300621F89EC; Mon, 22 Oct 2012 03:07:08 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LyEBR-1TKh2J2VdN-015PtV; Mon, 22 Oct 2012 06:07:04 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Mon, 22 Oct 2012 13:06:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> References: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:jhPbu8Oj6KWdzEYlfaIoDuhMQrjQ4xqCIECf2LoJGHC +j92+N5fqRsq9PwkP2R9BgB9MBkY/UfKFRuAWYkQHPPxCQBeux S/qbKOoJfCbin68fVU9oj2GlNVMFL+D0SvKVJXAzb3RlCdqhwy fzyLvZDYVdO0j1hqlpBclxtSAmdQp+O/UMIYrpKIDgxrxmGR3Y 4hWfzq3YQkSaJkp5Hu/Lbed6cvNnKqApL5QFmiKdJMQbA/ad7Q gAZsTueGuzReLWEFUG5SjkgM2kA+oUGY/QoLLwm9HrrldUEc3A 0o+jMZC3e2bi2PNp7gdd2zr+CQtCanhM8XAoHhZaeJCD8ttiu+ sgIPEUJADxvn0dVl+3gxk0aJv2ewI3Sega2F2dfNss8V/mMZX2 wqfjjYMqw6qjw== Cc: radext@ietf.org, abfab@ietf.org, pcp-chairs@tools.ietf.org, emu@ietf.org, "Zhangdacheng \(Dacheng\)" , dime@ietf.org, eap@frascone.com Subject: [radext] Tweaking EAP (RFC 3748) 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, 22 Oct 2012 10:07:09 -0000 On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> Hi Sam, Please also share this discussion with EAP WG and = EMU > Alper> WG mailing lists. That's where the EAP expertise is and they > Alper> should chime in, given that you are proposing to modify EAP > Alper> applicability statement. >=20 > The eap applicability statement update is a charter item of > ABFAB. We've agreed it will be last called in EMU. > Since it's a work item of abfab, it should be discussed on that list. > You're certainly free to let people know that the discussion if taking > place, although we've done that several times before. Sam, The type of changes you are talking about are well beyond the = "applicability statement changes" that ABFAB is chartered to make. Now you are discussing how EAP can be executed in a client-driven style = (as opposed to network driven), how server-initiated EAP = re-authentication may not be supported, how authorization parameters = (especially the session lifetime) is not set by the AAA server.=20 We need EAP and AAA expertise to get involved in the discussion. Not = only when ABFAB WG thinks it is done, but especially from the get go. This, IMHO, is re-engineering EAP and associated AAA procedures. Alper From hartmans@painless-security.com Mon Oct 22 05:51:02 2012 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 38F0821F8A87; Mon, 22 Oct 2012 05:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.909 X-Spam-Level: X-Spam-Status: No, score=0.909 tagged_above=-999 required=5 tests=[AWL=3.508, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrcmBfjH27p0; Mon, 22 Oct 2012 05:51:01 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4B29921F8842; Mon, 22 Oct 2012 05:51:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 1A7632026C; Mon, 22 Oct 2012 08:50:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6B5CB4AD5; Mon, 22 Oct 2012 08:50:56 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> Date: Mon, 22 Oct 2012 08:50:56 -0400 In-Reply-To: <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> (Alper Yegin's message of "Mon, 22 Oct 2012 13:06:40 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, abfab@ietf.org, pcp-chairs@tools.ietf.org, emu@ietf.org, "Zhangdacheng \(Dacheng\)" , dime@ietf.org, eap@frascone.com Subject: Re: [radext] Tweaking EAP (RFC 3748) 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, 22 Oct 2012 12:51:02 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: >>>>>> "Alper" == Alper Yegin writes: >> Alper> Hi Sam, Please also share this discussion with EAP WG and EMU Alper> WG mailing lists. That's where the EAP expertise is and they Alper> should chime in, given that you are proposing to modify EAP Alper> applicability statement. >> >> The eap applicability statement update is a charter item of >> ABFAB. We've agreed it will be last called in EMU. Since it's a >> work item of abfab, it should be discussed on that list. You're >> certainly free to let people know that the discussion if taking >> place, although we've done that several times before. Alper> Sam, Alper> The type of changes you are talking about are well beyond the Alper> "applicability statement changes" that ABFAB is chartered to Alper> make. First, I definitely encourage you to involve anyone in any IETF WG discussion you believe will help form a better consensus. So, absolutely, encourage people who you believe should join the discussion to do so. I am a bit confused by your message, because I'm not discussing changing EAP, only discussing how some issues that seem relatively likely to come up will influence applying EAP authentication to application authentication. My intent is to document existing, potentially hard to understand aspects of EAP so that people can better apply EAP to their applications. Thanks, --Sam From alper.yegin@yegin.org Tue Oct 23 01:09:16 2012 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 65D0321F8464; Tue, 23 Oct 2012 01:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leU1FS7HICmv; Tue, 23 Oct 2012 01:09:14 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 4975921F84B1; Tue, 23 Oct 2012 01:09:14 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MKHde-1TOvdh1gIA-0025Fn; Tue, 23 Oct 2012 04:08:33 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Tue, 23 Oct 2012 11:08:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <47A4DA97-971F-4292-98D7-FF28A9CAB88C@yegin.org> References: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:8yeC5v3uIkV11ucL5pEiYfjPbV6/f2fypAHjb2NVST0 geVIFTCbBDuhj83eim+SDdQjIgI0l/jpj11Txyi29qmH2IUgE+ dFVlITB/0YnWBWB1ka7vA9+M/gOi51biZf7CMVDx5AXttz193s j+M+9Ttd4QzlsiXuaHFWoeZUFCYHqkeaW3paXuHGFsVW5invpU GkzPw2V1niY2lJDeiEEXXoMIWHk84gdMioEHMcQYBomxXdj9zV Fv/Ea24uMFyXjYRBZSSiGi8cCGkt+ZuCvod+HoW8/I8qWzDlTe xCbNdLp8OOj8Fu7dbI16+NOLK9FcA+c5LEU5kj1rh48NcMUz/7 lDU8dcAf0b1s6PzeC+mOfIhDo8hV7D0stM/pJmxK8gHmyFbtFG SRXPZ2frzcwHw== Cc: radext@ietf.org, abfab@ietf.org, pcp-chairs@tools.ietf.org, emu@ietf.org, "Zhangdacheng \(Dacheng\)" , dime@ietf.org, eap@frascone.com Subject: Re: [radext] Tweaking EAP (RFC 3748) 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, 23 Oct 2012 08:09:16 -0000 >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: >=20 >>>>>>> "Alper" =3D=3D Alper Yegin writes: >>>=20 > Alper> Hi Sam, Please also share this discussion with EAP WG and = EMU > Alper> WG mailing lists. That's where the EAP expertise is and they > Alper> should chime in, given that you are proposing to modify EAP > Alper> applicability statement. >>>=20 >>> The eap applicability statement update is a charter item of >>> ABFAB. We've agreed it will be last called in EMU. Since it's a >>> work item of abfab, it should be discussed on that list. You're >>> certainly free to let people know that the discussion if taking >>> place, although we've done that several times before. >=20 > Alper> Sam, >=20 > Alper> The type of changes you are talking about are well beyond = the > Alper> "applicability statement changes" that ABFAB is chartered to > Alper> make. =20 >=20 > First, I definitely encourage you to involve anyone in any IETF WG > discussion you believe will help form a better consensus. > So, absolutely, encourage people who you believe should join the > discussion to do so. >=20 Good. Please remember to keep these groups updated as you progress the = discussion. > I am a bit confused by your message, because I'm not discussing = changing > EAP, only discussing how some issues that seem relatively likely to = come > up will influence applying EAP authentication to application > authentication. I captured the issues you are raising as below: > how EAP can be executed in a client-driven style (as opposed to = network driven), how server-initiated EAP re-authentication may not be = supported, how authorization parameters (especially the session = lifetime) is not set by the AAA server.=20 These have potential impact on the EAP layer, and EAP lower-layer (both = the EAP peer to EAP Authenticator leg, and the EAP Authenticator to EAP = Authentication Server leg [a.k.a, the AAA protocol]). We need to fully = understand the implications. These are not mere "applicability" issues.=20= The ABFAB applicability update in my understanding is nothing more than = removing the somewhat artificial constraints in RFC 3748 that was = blocking the use of EAP for anything other than network access = authentication. The types of issues you are discussing now are well = beyond that. > My intent is to document existing, potentially hard to understand > aspects of EAP so that people can better apply EAP to their > applications. >=20 Alper > Thanks, >=20 > --Sam > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From trac+radext@trac.tools.ietf.org Tue Oct 23 12:35:12 2012 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 788761F0C99 for ; Tue, 23 Oct 2012 12:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUe+QG4Dhz+k for ; Tue, 23 Oct 2012 12:35:12 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E388A1F0C91 for ; Tue, 23 Oct 2012 12:35:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:34561 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TQkFK-0002tc-NB; Tue, 23 Oct 2012 21:34:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-radext-radius-extensions@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Tue, 23 Oct 2012 19:34:38 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/129#comment:1 Message-ID: <079.62e8565f6bc1ad11fe632207943d59f4@trac.tools.ietf.org> References: <064.e74aafa86b70590c821aa1d5f8de333f@trac.tools.ietf.org> X-Trac-Ticket-ID: 129 In-Reply-To: <064.e74aafa86b70590c821aa1d5f8de333f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-extensions@tools.ietf.org, aland@deployingradius.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@networkradius.com, avi@bridgewatersystems.com Resent-Message-Id: <20121023193509.E388A1F0C91@ietfa.amsl.com> Resent-Date: Tue, 23 Oct 2012 12:35:00 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #129: 9.2 nit inconsistent long extended type vsa example X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 19:35:12 -0000 #129: 9.2 nit inconsistent long extended type vsa example Changes (by aland@…): * status: new => closed * resolution: => fixed Comment: I've updated the source with a corrected version, and will add in when the next version is issued. -- -------------------------+------------------------------------------------- Reporter: peterd@… | Owner: draft-ietf-radext-radius- Type: defect | extensions@… Priority: trivial | Status: closed Component: radius- | Milestone: extensions | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From jouni.nospam@gmail.com Wed Oct 24 14:25:48 2012 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 45B3921F8BBF for ; Wed, 24 Oct 2012 14:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPVbA3QAmzz1 for ; Wed, 24 Oct 2012 14:25:47 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5607A21F860C for ; Wed, 24 Oct 2012 14:25:47 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so813777wib.13 for ; Wed, 24 Oct 2012 14:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=dTlB9GMQXxCj1i1eVkLt3MLth3CHCn27acQM+iKkfgE=; b=mX8u/IfIkJqpXRg9mSKmbsNx7E2RrDZRIN+6uyiZHD2E5iQsK5A8eXmQk660n1yjUC wOUB2H953SPxBkPNejPdvozs3PEO0rH8HGe5NPxiBpcEycWZNeRWnSYgbY8GpSxhiQNu g0vlKueny4z6XOF4LRpbCEotO0LAIlK6rB0nAgSx5Fhn3m6TtXNhg7tjEXyu0WbXpAGQ I3Ga9xQWOKBlrIc5pC3+eZIn6Evl9pJJ5Pir0FbZ/ojKEDdT8FgYJA8Cb7N1JNQEhXbO YPTivy7rbFVo64zh1PpIe7QiXZKC0G0cJKSmK/67R9bCr9Id6zOwzlJvrgUdbKDOOY4e KExg== Received: by 10.216.139.36 with SMTP id b36mr9887692wej.160.1351113946519; Wed, 24 Oct 2012 14:25:46 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id p4sm7216395wix.0.2012.10.24.14.25.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 14:25:43 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 25 Oct 2012 00:25:37 +0300 Message-Id: <366D275B-27B9-4101-9687-3FE762EEF0BD@gmail.com> To: radext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [radext] draft agenda is available 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, 24 Oct 2012 21:25:48 -0000 Folks, I just uploaded very drafty draft agenda for the Atlanta meeting: http://tools.ietf.org/wg/radext/agenda?item=agenda-85-radext.html - Jouni & Mauricio From jouni.nospam@gmail.com Mon Oct 29 14:56:01 2012 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 8D99C21F870A for ; Mon, 29 Oct 2012 14:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVMhd+5cLwky for ; Mon, 29 Oct 2012 14:56:01 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1781621F86DD for ; Mon, 29 Oct 2012 14:55:49 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so2701210eek.31 for ; Mon, 29 Oct 2012 14:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=i4nFP6oY/kV4NSS+mo5p4QubmpFo9eJbMasGX2BCa0E=; b=bkdd3bNp6bdT9A3zhq3HQ7o+HSJrfH+gobuaGddIiD7YzIEXSJtqv+8N463PonY7qA xVe78OP7F20eJEIaW3Q3eoRlOGnI8w01n7Jjki+3tWnvgutDocPfdqu9h6VHmIx7URXQ OCUX45ZXJM2BZmmTkB8un5V0tSiFWA7zmOURVkw3ss2+MbwyGLv7z0hCxjZ9Q749Bq+j VGS8b5aySKE8Y0RpSBJF71k9BuxcaiJOzR0nQZcfjY4Xopjf58KJ1NtdOrBwUMXCatOt RbTDSnPSU57Bm1yXDEUlZTJqQnkOC+qWlNM4GPMlBdFo9dKSLsi+oa9ePvLX9knshxh6 X6tA== Received: by 10.14.0.198 with SMTP id 46mr66122694eeb.21.1351547749338; Mon, 29 Oct 2012 14:55:49 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id o47sm25356934eem.11.2012.10.29.14.55.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 14:55:48 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 29 Oct 2012 23:55:45 +0200 Message-Id: To: radext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: radext-chairs@tools.ietf.org Subject: [radext] Atlanta meeting presentation slides 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, 29 Oct 2012 21:56:01 -0000 Folks, Those who have a presentation slot in Atlanta RADEXT meeting send your slides to the chairs by Monday morning on the IETF week. - Jouni & Mauricio From iesg-secretary@ietf.org Tue Oct 30 07:46:18 2012 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 5890F21F85C2; Tue, 30 Oct 2012 07:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPPmqe0RrS3I; Tue, 30 Oct 2012 07:46:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC15C21F85AC; Tue, 30 Oct 2012 07:46:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121030144617.13595.68895.idtracker@ietfa.amsl.com> Date: Tue, 30 Oct 2012 07:46:17 -0700 Cc: radext@ietf.org Subject: [radext] Last Call: (RADIUS attributes for IPv6 Access Networks) to Proposed Standard X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:46:18 -0000 The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'RADIUS attributes for IPv6 Access Networks' 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 2012-11-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 This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access/ballot/ No IPR declarations have been submitted directly on this I-D.