From internet-drafts@ietf.org Wed Jan 2 13:57:14 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F8621F8795; Wed, 2 Jan 2013 13:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 lOe8e9WgZz1U; Wed, 2 Jan 2013 13:57:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347A621F8798; Wed, 2 Jan 2013 13:57:14 -0800 (PST) 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.37 Message-ID: <20130102215713.6839.57273.idtracker@ietfa.amsl.com> Date: Wed, 02 Jan 2013 13:57:13 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-nai-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: Wed, 02 Jan 2013 21:57:14 -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 : The Network Access Identifier Author(s) : Alan DeKok Filename : draft-ietf-radext-nai-00.txt Pages : 19 Date : 2012-12-22 Abstract: In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. This document is a revised version of RFC 4282 [RFC4282], which addresses issues with international character sets, as well as a number of other corrections to the previous document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-nai There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-nai-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wdec@cisco.com Thu Jan 3 05:10:36 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063BD21E8041 for ; Thu, 3 Jan 2013 05:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 EtMvMy3eZwhA for ; Thu, 3 Jan 2013 05:10:34 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3190C21E8039 for ; Thu, 3 Jan 2013 05:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15357; q=dns/txt; s=iport; t=1357218634; x=1358428234; h=from:to:subject:date:message-id:mime-version; bh=jOsuoTjsW5343RXgSyYpLi24dSwA5R6rOmdai1hK9QM=; b=Qp6jXzCTglQVMdodus+9E9tbKLdTuASmvWb/2xucaSTxTbrX1/9ye6Vd dxMwdwWeI93sc+2jpligo/m/2ynzwihG4EguWzFElaAOPqbopASB6MFKB H2MUDS5U7Rm0ftTOty4a4eFZXhebl9BG6j/i/UcdoIEfQlJAGhkUM6IKs 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUMAEWC5VCtJV2Z/2dsb2JhbAAVMIF/S7sFFnOCHgEBAQQBAQFoAxcGARkDAQILHS4LFAkKBAESCAGICgyFba9hjFcbg0dhA5coiBeHFYJ0gXE1 X-IronPort-AV: E=Sophos;i="4.84,403,1355097600"; d="scan'208,217";a="158212053" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 03 Jan 2013 13:10:33 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r03DAXdM014276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jan 2013 13:10:33 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.50]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 07:10:33 -0600 From: "Wojciech Dec (wdec)" To: "Benoit Claise (bclaise)" , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radext@ietf.org" Thread-Topic: [radext] Fwd: [OPS-DIR] OPS-DIR Review of draft-ietf-radext-ipv6-access-13 Thread-Index: AQHN6bO1pJAU/hhQL0+PWSyODub5KA== Date: Thu, 3 Jan 2013 13:10:32 +0000 Message-ID: <19F346EB777BEE4CB77DA1A2C56F20B3182C82@xmb-aln-x05.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.61.105.183] Content-Type: multipart/alternative; boundary="_000_19F346EB777BEE4CB77DA1A2C56F20B3182C82xmbalnx05ciscocom_" MIME-Version: 1.0 Subject: [radext] Fwd: [OPS-DIR] OPS-DIR Review of draft-ietf-radext-ipv6-access-13 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, 03 Jan 2013 13:10:36 -0000 --_000_19F346EB777BEE4CB77DA1A2C56F20B3182C82xmbalnx05ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, Apologies for not caching this one. For some reason our corporate mail filt= er classified messages to the draft-ietf=85 alias as "Spam". I will be posting a ver 14 shortly, however there are two comments/nits tha= t I need to address here: 1. Section 3.4. ---snip--- But there is no mention of how the pool itself is defined. A reference to t= he document where this has been specified would be useful for the reader. ---snip--- Reply> Strictly speaking the pool definition is something subject to vendor= implementation (as is any of the configuration of Radius too). Having chec= ked some of the other Radius drafts, eg rfc2869, which defines the frame-po= ol, I did not find descriptive text about how the pool is configured, so it= appears ok to leave the text as is. 2. Non rfc2606 FQDN nit. TBH I can't find any FQDN that is being used in the text or an explicit IP = address, so this seems to be a misinterpretation by the tool of something e= lse. Regards, Woj.. ________________________________ * From: Benoit Claise > * To: "draft-ietf-radext-ipv6-access at tools.ietf.org" > * Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" >, "radext at ietf.org" > * Date: Tue, 04 Dec 2012 10:56:19 +0100 * In-reply-to: <80A0822C5E9A4440A5117C2F4CD36A640469F0E9 at DEMUEXC006.= nsn-intra.net> * References: <80A0822C5E9A4440A5117C2F4CD36A640469F0E9 at DEMUEXC006.n= sn-intra.net= > ________________________________ Hi Authors, Can you please address Mehmet's comments. Regards, Benoit -------- Original Message -------- Subject: [OPS-DIR] OPS-DIR Review of draft-ietf-radext-ipv6-access-1= 3 Date: Tue, 20 Nov 2012 14:38:15 +0100 From: Ersue, Mehmet (NSN - DE/Munich) To: , I reviewed the draft "RADIUS attributes for IPv6 Access Networks" ( draft-ietf-radext-ipv6-access-13.txt) for its operational impact. Summary: Intended status: Standards Track Current status: Waiting for AD Go-Ahead The document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments, which are: 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 document follows the standard method for Radius attribute definition. As such the attributes and their configuration has been sufficiently described. I do not see any blocking issues. The document seems to be ready for publication as Proposed Standard. Minor issues: - Section 4.4. Delegated-IPv6-Prefix-Pool I am not a AAA-NAS expert, however section 4.4. defines the Delegated-IPv6-Prefix-Pool attribute containing the name of an assigned pool that SHOULD be used to select an IPv6 delegated prefix for the user on the NAS. But there is no mention of how the pool itself is defined. A reference to the document where this has been specified would be useful for the reader. - There is one nit error (lines 453/454) which needs to be fixed: ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 453 0+ 0+ 0 0 0+ TBA4 Delegated-IPv6-Prefix-Pool 454 0+ 0+ 0 0 0+ TBA5 Stateful-IPv6-Address-Pool - There is one nit warning: =3D=3D There are 1 instance of lines with non-RFC2606-compliant FQDNs in th= e document. Cheers, Mehmet _______________________________________________ OPS-DIR mailing list OPS-DIR at ietf.org https://www.ietf.org/mailman/listinfo/ops-dir ________________________________ * Prev by Date: [radext] Fwd: Gen-art review of draft-ietf-radext-ipv6-= access-13 * Next by Date: [radext] WG Action: Rechartered RADIUS EXTensions (rade= xt) * Previous by thread: [radext] Fwd: Gen-art review of draft-ietf-radext= -ipv6-access-13 * Next by thread: [radext] WG Action: Rechartered RADIUS EXTensions (ra= dext) * Index(es): * Date * Thread Note Well: Messages sent to this mailing list are the opinions of the sende= rs and do not imply endorsement by the IETF. --_000_19F346EB777BEE4CB77DA1A2C56F20B3182C82xmbalnx05ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <13AF749E7915A848A7D7FF6AD0B3A026@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi All,<= /div>

Apologie= s for not caching this one. For some reason our corporate mail filter class= ified messages to the draft-ietf=85 alias as "Spam".

I will b= e posting a ver 14 shortly, however there are two comments/nits that I need= to address here:

  1. Section 3= .4. 
---snip---
But there is no mention of how the po= ol itself is defined. A reference to the document where this has bee= n specified would be useful
for the reader.
---snip---
Reply> Strictly speaki=
ng the pool definition is something subject to vendor implementation (as is=
 any of the configuration of Radius too). Having checked some of the other =
Radius drafts, eg rfc2869, which defines the frame-pool, I did not find des=
criptive text about how the pool is configured, so it appears ok to leave t=
he text as is.

2. Non rfc2606 FQDN nit.<=
/pre>

TBH I can't find any FQDN=
 that is being used in the text or an explicit IP address, so this seems to=
 be a misinterpretation by the tool of something else.





Regards,


Woj..












Hi Authors,



Can you please address Mehmet's comments.



Regards, Benoit






-------- Original Message --------





Subject: 
[OPS-DIR] OPS-DIR Review of draft-ietf-radext-ipv6-access-13




Date: 
Tue, 20 Nov 2012 14:38:15 +0100




From: 
Ersue, Mehmet (NSN - DE/Munich) 
<mehmet.ersue at nsn.com>




To: 
<ops-dir at ietf.org>,

<draft-ietf-radext-ipv6-access at tools.ietf.org>










I reviewed the draft "RADIUS attributes for IPv6 Access Networks&=
quot; (
draft-ietf-radext-ipv6-access-13.txt) for its operational impact.=20

Summary:
Intended status: Standards Track
Current status: Waiting for AD Go-Ahead=20

The document specifies additional IPv6 RADIUS attributes useful in
residential broadband network deployments, which are:
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 document follows the standard method for Radius attribute
definition. As such the attributes and their configuration has been
sufficiently described.

I do not see any blocking issues.  The document seems to be ready for
publication as Proposed Standard.


Minor issues:

- Section 4.4. Delegated-IPv6-Prefix-Pool

I am not a AAA-NAS expert, however section 4.4. defines the
Delegated-IPv6-Prefix-Pool attribute containing the name of an assigned
pool that SHOULD be used to select an IPv6 delegated prefix for the user
on the NAS. But there is no mention of how the pool itself is defined. A
reference to the document where this has been specified would be useful
for the reader.


- There is one nit error (lines 453/454) which needs to be fixed:

** There are 2 instances of too long lines in the document, the longest
one
     being 3 characters in excess of 72.


453	   0+      0+     0      0         0+      TBA4
Delegated-IPv6-Prefix-Pool
454	   0+      0+     0      0         0+      TBA5
Stateful-IPv6-Address-Pool


- There is one nit warning:

=3D=3D There are 1 instance of lines with non-RFC2606-compliant FQDNs in th=
e
      document.

Cheers,=20
Mehmet=20


_______________________________________________
OPS-DIR mailing list
OPS-DIR at ietf.org
https://www.ietf.org/mailman/listinfo/ops-d=
ir






















Note Well: Messages sent=
 to this mailing list are the opinions of the senders and do not imply endo=
rsement by the IETF.
--_000_19F346EB777BEE4CB77DA1A2C56F20B3182C82xmbalnx05ciscocom_-- From internet-drafts@ietf.org Thu Jan 3 05:14:35 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1DF21E8045; Thu, 3 Jan 2013 05:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 zO6IeFrIfl54; Thu, 3 Jan 2013 05:14:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6F821F8633; Thu, 3 Jan 2013 05:14:34 -0800 (PST) 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.37 Message-ID: <20130103131434.9945.46324.idtracker@ietfa.amsl.com> Date: Thu, 03 Jan 2013 05:14:34 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-14.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, 03 Jan 2013 13:14:35 -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) : Wojciech Dec Behcet Sarikaya Glen Zorn David Miles Benoit Lourdelet Filename : draft-ietf-radext-ipv6-access-14.txt Pages : 12 Date : 2013-01-03 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf@augustcellars.com Thu Jan 3 20:05:30 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315BE21F8E67 for ; Thu, 3 Jan 2013 20:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 3ULY9NJDxGsD for ; Thu, 3 Jan 2013 20:05:29 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 695DB21F8E58 for ; Thu, 3 Jan 2013 20:05:26 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 05C8638F12; Thu, 3 Jan 2013 20:05:24 -0800 (PST) From: "Jim Schaad" To: "Alan DeKok" Date: Thu, 3 Jan 2013 20:05:02 -0800 Message-ID: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3pUUPml1eCg+lXTZ2MtIY8D/jlNQ== Content-Language: en-us Cc: radext@ietf.org Subject: [radext] Comments on draft-ietf-radext-nai-00 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, 04 Jan 2013 04:05:30 -0000 In section 2.3, is there still an absolute limit to the length of the NAI with the possibility of using the Radius fragmentation draft to extend them longer? While it would not be generally reasonable, it might remove the restriction. In Section 2.11, Given the potential registration of new top level domains, do you still want to keep fred@example as an invalid NAI? What if somebody succeeds in getting example as a top level domain? (Which I sincerely hope could never happen.) In Section 2.7, Two issues: a) I am unclear if one should do the comparison and routing based on the entire utf8-realm portion of the name, or if one can (and perhaps should be able to) do the routing based on the set of labels that occur in the utf8-realm. As part of this one wonders about doing any matching of utf8-realm names and if that needs to be discussed as well b) I find the last paragraph to be very confusing. The use of or would make it appear that it would be one of the items listed, however based on what I would expect it could be any or all of the elements listed. Grammatically this is very fuzzy. Additionally, do you want to pre-view section 2.9 and make the DNS Host name be an explicit ASCII version of the DNS host name rather than allowing people to think it might be the internalized version? Jim From bclaise@cisco.com Fri Jan 4 02:51:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2A921F8E92 for ; Fri, 4 Jan 2013 02:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 FG5wa1WYy4sW for ; Fri, 4 Jan 2013 02:51:14 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id DF5DD21F8667 for ; Fri, 4 Jan 2013 02:51:13 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r04Ap9c9003362; Fri, 4 Jan 2013 11:51:10 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r04Ap9p7003717; Fri, 4 Jan 2013 11:51:09 +0100 (CET) Message-ID: <50E6B41D.5020201@cisco.com> Date: Fri, 04 Jan 2013 11:51:09 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alan DeKok References: <50C1CA9F.40100@cisco.com> <50C210F8.5060107@cisco.com> <50DB4F89.5090909@deployingradius.com> In-Reply-To: <50DB4F89.5090909@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , draft-ietf-radext-radius-extensions@tools.ietf.org Subject: Re: [radext] AD review: draft-ietf-radext-radius-extensions 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, 04 Jan 2013 10:51:18 -0000 Alan, Thanks for addressing my feedback. See inline > Benoit Claise wrote: > >> Do you want to have a table like in RFC 2865 section 5.44 with the list >> of attributes, explaining whether or not they can be part of the sub-TLV, and >> with which multiplicity. > Quite likely, yes. I don't see this table. > >> 5. >> * New specifications SHOULD NOT request allocation from the standard >> Attribute Type Space (i.e. Attributes 1 through 255). That space >> is deprecated. >> >> Deprecated: is it the right term? >> Maybe you meant: Assignment from that space is not to be used. > IANA can't do that. > >> In this case, this contradicts >> * specifcumber of attributes >> (i.e. less than ten) should have all allocations made from >> the standard space. > I'll update that to change the allocation strategy to be a bit more > flexible. I still see the two contradictory sentences regarding the standard space : * New specifications SHOULD NOT request allocation from the standard Attribute Type Space (i.e. Attributes 1 through 255). That space is deprecated. * specifications which allocate a small number of attributes (i.e. less than ten) should have all allocations made from the standard space. Btw, RFC 2119 should be used for interoperability sentences, not process ones. > >> >> 8. >> section 10.3.4 >> * specifications which allocate a small number of attributes >> (i.e. less than ten) should have all allocations made from >> the standard space. >> >> * specifications which allocate a large number of attributes >> (i.e. ten or more) should have all allocations made from the >> extended space. >> Instead of using a number, which would anyway not be relevant very long, why don't you have a relative number? >> For example, instead of "i.e. ten or more", "compared to the remaining available number of entries in the standard space" > OK. I'll just change it to "many" attributes. I don't see that change. There is also a connection with the previous point > >> 2. >> Vendor-Id >> >> The 4 octets are the SMI Network Management Private Enterprise >> Code of the Vendor in network byte order. >> >> Give a reference to http://www.iana.org/assignments/enterprise-numbers >> Note: there are multiple instances of that sentence. > OK. Editorial OLD [SMI] http://www.iana.org/assignments/enterprise-numbers NEW [PEN] http://www.iana.org/assignments/enterprise-numbers >> 9. >> This document updates: 2865 , 2866 , 3575 , 5176 , 6158 >> My guess is that those should be normative references > Sure... it's an informational document, but OK. Maybe I'll stand corrected, but I think this is the right thing to do. Please apply the changes. I'll send this document to IETF last call. Treat this feedback as part of the last call. Regards, Benoit From hartmans@painless-security.com Fri Jan 4 05:20:00 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A2721F88CA for ; Fri, 4 Jan 2013 05:20:00 -0800 (PST) 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 3EU58-HlgljH for ; Fri, 4 Jan 2013 05:20:00 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 26FC821F88A5 for ; Fri, 4 Jan 2013 05:19:59 -0800 (PST) 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 2AD1C2026F; Fri, 4 Jan 2013 08:17:01 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A272743F0; Fri, 4 Jan 2013 08:19:56 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com> Date: Fri, 04 Jan 2013 08:19:56 -0500 In-Reply-To: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com> (Jim Schaad's message of "Thu, 3 Jan 2013 20:05:02 -0800") 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, Alan DeKok Subject: Re: [radext] Comments on draft-ietf-radext-nai-00 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, 04 Jan 2013 13:20:00 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> In section 2.3, is there still an absolute limit to the length Jim> of the NAI with the possibility of using the Radius Jim> fragmentation draft to extend them longer? While it would not Jim> be generally reasonable, it might remove the restriction. More generally, to what extent is NAI a RADIUS concept and to what extent is it an AAA concept and potentially broader. Perhaps it's better to say that NAIs that MAY be transported over RADIUS have this limitation? From bclaise@cisco.com Fri Jan 4 06:12:08 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A328F21F844C for ; Fri, 4 Jan 2013 06:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.756 X-Spam-Level: X-Spam-Status: No, score=-9.756 tagged_above=-999 required=5 tests=[AWL=0.843, 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 ZC98aECCdsoc for ; Fri, 4 Jan 2013 06:12:08 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 019D821F8446 for ; Fri, 4 Jan 2013 06:12:00 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r04EBwHp024598; Fri, 4 Jan 2013 15:11:58 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r04EBv5w013211; Fri, 4 Jan 2013 15:11:57 +0100 (CET) Message-ID: <50E6E32D.7000001@cisco.com> Date: Fri, 04 Jan 2013 15:11:57 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alan DeKok References: <50C1CA9F.40100@cisco.com> <50C210F8.5060107@cisco.com> <50DB4F89.5090909@deployingradius.com> <50E6B41D.5020201@cisco.com> In-Reply-To: <50E6B41D.5020201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , draft-ietf-radext-radius-extensions@tools.ietf.org Subject: Re: [radext] AD review: draft-ietf-radext-radius-extensions 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, 04 Jan 2013 14:12:08 -0000 Alan, >>> 9. >>> This document updates: 2865 , >>> 2866 , 3575 >>> , 5176 >>> , 6158 >>> >>> My guess is that those should be normative references >> Sure... it's an informational document, but OK. > Maybe I'll stand corrected, but I think this is the right thing to do. > Please apply the changes. After some more investigation, and reading RFC 3967 ... This document updates RFC 2865, standard track RFC 2866, informational RFC 3575, standard track RFC 5176, informational RFC 6158, BCP I'm wondering why RFC 2866 and RFC 5176 were informational in the first place. Maybe someone with a long history in the WG could shed some light? From RFC 3967, we need to have a clear idea on the downref before the IETF Last Call For Standards Track or BCP documents requiring normative reference to documents of lower maturity, the normal IETF Last Call procedure will be issued, with the need for the downward reference explicitly documented in the Last Call itself. Any community comments on the appropriateness of downward references will be considered by the IESG as part of its deliberations. Regards, Benoit From aland@deployingradius.com Fri Jan 4 06:12:39 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99ABE21F88A5 for ; Fri, 4 Jan 2013 06:12:39 -0800 (PST) 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 h9Lju653sPlW for ; Fri, 4 Jan 2013 06:12:33 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC0B821F844F for ; Fri, 4 Jan 2013 06:12:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D8FFD22410D6; Fri, 4 Jan 2013 15:11:36 +0100 (CET) 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 HGsrQpauBIkY; Fri, 4 Jan 2013 15:11:34 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 3335F22409C6; Fri, 4 Jan 2013 15:11:34 +0100 (CET) Message-ID: <50E6E314.2080001@deployingradius.com> Date: Fri, 04 Jan 2013 09:11:32 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Benoit Claise References: <50C1CA9F.40100@cisco.com> <50C210F8.5060107@cisco.com> <50DB4F89.5090909@deployingradius.com> <50E6B41D.5020201@cisco.com> In-Reply-To: <50E6B41D.5020201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , draft-ietf-radext-radius-extensions@tools.ietf.org Subject: Re: [radext] AD review: draft-ietf-radext-radius-extensions 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, 04 Jan 2013 14:12:39 -0000 Benoit Claise wrote: > I still see the two contradictory sentences regarding the standard space : > > * New specifications SHOULD NOT request allocation from the standard > Attribute Type Space (i.e. Attributes 1 through 255). That space > is deprecated. > > * specifications which allocate a small number of attributes > (i.e. less than ten) should have all allocations made from > the standard space. > > Btw, RFC 2119 should be used for interoperability sentences, not process > ones. OK. I'll just delete the first bullet point. The point immediately after it covers the subject: * Specifications should not request allocation from a specific space. The IANA considerations given in Section 9, below, should be sufficient for attribute allocation. >>> For example, instead of "i.e. ten or more", "compared to the >>> remaining available number of entries in the standard space" >> OK. I'll just change it to "many" attributes. > I don't see that change. > There is also a connection with the previous point I'll fix that. > Editorial > OLD > [SMI] http://www.iana.org/assignments/enterprise-numbers > > NEW > [PEN] http://www.iana.org/assignments/enterprise-numbers Fixed, thanks. >>> My guess is that those should be normative references >> Sure... it's an informational document, but OK. > Maybe I'll stand corrected, but I think this is the right thing to do. > Please apply the changes. Done. Alan DeKok. From d.b.nelson@comcast.net Fri Jan 4 06:27:44 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8626E21F88C8 for ; Fri, 4 Jan 2013 06:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 9ERqK4SPgNi4 for ; Fri, 4 Jan 2013 06:27:44 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id E957B21F88B9 for ; Fri, 4 Jan 2013 06:27:43 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA11.westchester.pa.mail.comcast.net with comcast id jp3R1k00316LCl05BqTj0s; Fri, 04 Jan 2013 14:27:43 +0000 Received: from newton ([24.61.179.177]) by omta06.westchester.pa.mail.comcast.net with comcast id jqTc1k00p3q2Njc3SqTiCu; Fri, 04 Jan 2013 14:27:43 +0000 From: "David B. Nelson" To: "'Benoit Claise'" , "'Alan DeKok'" References: <50C1CA9F.40100@cisco.com> <50C210F8.5060107@cisco.com><50DB4F89.5090909@deployingradius.com> <50E6B41D.5020201@cisco.com> <50E6E32D.7000001@cisco.com> Date: Fri, 4 Jan 2013 09:27:39 -0500 Message-ID: <1AD287816CAE4B46A588B1D8AA690CBC@newton> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50E6E32D.7000001@cisco.com> Thread-Index: Ac3qhZ2lg6inl0WnSeecYzqiwseetgAARmkg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357309663; bh=SIpKiNZ852Zus2fmhCq/Qx1Jc9owhGMiotczDUPQ2yg=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=SKx1tJgbCSZ1/RTm6+QU3aX5C2LwG9O6s3jb3wCgVB229T6x7w7tiOYHEB3WIdgFw 8rp+bePEoN0/byA3Q8NETuN9tWzm/WhrZFIVE+Ph+qnjJoaYMh2YK58SuGl24pSjJB 69xU9sV4CIBLutHnFc/OKeDaZge1jKK3s/g5nmYJkN+MH4jmHQXM6Na8qTTHKSbFFk EBpqKxTUGZFFMsPm9lIUtkDmVuQA+XT92wiMAkOyi+TQ1vTVBQIddBuBI+HKwfroqj MF0xwzwVM5hklV9z66DS1WVsb3mN2phkNinmYQkSRi5nkA+cPaorYY4Azsn+D7LcTX R6G/WU8trdwfA== Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org Subject: Re: [radext] AD review: draft-ietf-radext-radius-extensions 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, 04 Jan 2013 14:27:44 -0000 Benoit Claise writes... > I'm wondering why RFC 2866 and RFC 5176 were informational > in the first place. Maybe someone with a long history in > the WG could shed some light? I've been involved since the second RADIUS BOF (for the RADIUS WG), so I remember some of this history. RADIUS Accounting was not considered as robust as RADIUS, for a number of reasons. I think one reasons was the lack of positive application layer acknowledgement that the data had been received and logged. Anyway, the IESG politics at the time dictated that Standards Track status would require enhancements to RADIUS Accounting beyond what the RADIUS user community would actively support. I think there were similar "maturity" arguments around Dynamic RADIUS. With the passage of time, and additional field experience, perhaps we would look at it differently today. Regards, Dave From iesg-secretary@ietf.org Fri Jan 4 06:35:15 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6F221F892F; Fri, 4 Jan 2013 06:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.815 X-Spam-Level: X-Spam-Status: No, score=-101.815 tagged_above=-999 required=5 tests=[AWL=0.784, 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 gkT6s+l9rLiD; Fri, 4 Jan 2013 06:35:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5D421F88EE; Fri, 4 Jan 2013 06:35:14 -0800 (PST) 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.37 Message-ID: <20130104143514.20728.47886.idtracker@ietfa.amsl.com> Date: Fri, 04 Jan 2013 06:35:14 -0800 Cc: radext@ietf.org Subject: [radext] Last Call: (Remote Authentication Dial In User Service (RADIUS) Protocol Extensions) 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: Fri, 04 Jan 2013 14:35:15 -0000 The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'Remote Authentication Dial In User Service (RADIUS) Protocol Extensions' 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 2013-01-18. 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 The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/ballot/ No IPR declarations have been submitted directly on this I-D. From bernard_aboba@hotmail.com Fri Jan 4 07:00:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9E521F88BC for ; Fri, 4 Jan 2013 07:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 AVj8PuuriD3h for ; Fri, 4 Jan 2013 07:00:48 -0800 (PST) Received: from blu0-omc1-s38.blu0.hotmail.com (blu0-omc1-s38.blu0.hotmail.com [65.55.116.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9071521F88B4 for ; Fri, 4 Jan 2013 07:00:48 -0800 (PST) Received: from BLU002-W189 ([65.55.116.7]) by blu0-omc1-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jan 2013 07:00:48 -0800 X-EIP: [SfLqrvVXBU1psvIVxMpzNS901ttcRSBw] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c31bce58-7ca7-4937-b690-c5867273e9d9_" From: Bernard Aboba To: Sam Hartman , Jim Schaad Date: Fri, 4 Jan 2013 07:00:47 -0800 Importance: Normal In-Reply-To: References: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jan 2013 15:00:48.0147 (UTC) FILETIME=[479DFE30:01CDEA8C] Cc: "radext@ietf.org" , Alan DeKok Subject: Re: [radext] Comments on draft-ietf-radext-nai-00 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, 04 Jan 2013 15:00:49 -0000 --_c31bce58-7ca7-4937-b690-c5867273e9d9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sam Hartman said:=20 > More generally=2C to what extent is NAI a RADIUS concept and to what > extent is it an AAA concept and potentially broader. > Perhaps it's better to say that NAIs that MAY be transported over RADIUS > have this limitation? [BA] This raises the question of what the definition of NAI is for the purp= ose of this document.=20 RFC 2486 defines the NAI as follows: The Network Access Identifier (NAI) is the userID submitted=0A= by the client during PPP authentication. =20 The definition was changed in RFC 4282: The Network Access Identifier (NAI) is the user identity submitted=0A= by the client during network access authentication. I am not sure that the above definition is still usable=2C because since RF= C 4282 was published=2C RADIUS has been=20 extended to handle authentication for more than just network access. For e= xample=2C RFC 5090 defines how to use=20 RADIUS for Digest Authentication (HTTP=2C SIP=2C etc.)=20 As a result=2C is it still valid to assume that the RADIUS User-Name Attrib= ute contains an NAI? I am not sure.=20 For example=2C RFC 5090 Section 2.2.1 includes the following statement: Correlation between User-Name and SIP-AOR AVP values is required just=0A= to avoid any user from registering or misusing a SIP-AOR that has=0A= been allocated to a different user. In the above statement=2C it would appear that the RADIUS User-Name Attribu= te is to be "correlated" with the SIP AOR. =20 Does the ABNF provided in this document apply to the contents of the RADIUS= User-Name in this case? Is a User-Name Attribute "correlated" with a SIP AOR an NAI? = --_c31bce58-7ca7-4937-b690-c5867273e9d9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sam Hartman said:

&= gt=3B More generally=2C to what extent is NAI a RADIUS concept and to what<= br>>=3B extent is it an AAA concept and potentially broader.
>=3B Pe= rhaps it's better to say that NAIs that MAY be transported over RADIUS
&= gt=3B have this limitation?

[BA] This raises the question of what th= e definition of NAI is for the purpose of this document.

RFC 2486 d= efines the NAI as follows:

      The Network =
Access Identifier (NAI) is the userID submitted=0A=
      by the client during PPP authentication.  

The definition was =
changed in RFC 4282:

      The Network Access Identifier (NAI) is th=
e user identity submitted=0A=
      by the client during network access authentication.

I am not s=
ure that the above definition is still usable=2C because since RFC 4282 was=
 published=2C RADIUS has been 
extended to handle authentication for mor=
e than just network access.  For example=2C RFC 5090 defines how to use RADIUS for Digest Authentication (HTTP=2C SIP=2C etc.) 

As a result=
=2C is it still valid to assume that the RADIUS User-Name Attribute contain=
s an NAI?

I am not sure. 

For example=2C RFC 5090 Section 2.2=
.1 includes the following statement:

   Correlation between User-Nam=
e and SIP-AOR AVP values is required just=0A=
   to avoid any user from registering or misusing a SIP-AOR that has=0A=
   been allocated to a different user.

In the above statement=2C it =
would appear that the RADIUS User-Name Attribute is to be "correlated" with=
 the SIP AOR.  

Does the ABNF provided in this document apply to the=
 contents of the RADIUS User-Name in this case?  Is a User-Name Attribute"correlated" with a SIP AOR an NAI?







=
= --_c31bce58-7ca7-4937-b690-c5867273e9d9_-- From bernard_aboba@hotmail.com Fri Jan 4 10:29:52 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183F821F8923 for ; Fri, 4 Jan 2013 10:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NjZ5MEwOcdr1 for ; Fri, 4 Jan 2013 10:29:51 -0800 (PST) Received: from blu0-omc2-s3.blu0.hotmail.com (blu0-omc2-s3.blu0.hotmail.com [65.55.111.78]) by ietfa.amsl.com (Postfix) with ESMTP id 82A5021F8911 for ; Fri, 4 Jan 2013 10:29:51 -0800 (PST) Received: from BLU002-W172 ([65.55.111.72]) by blu0-omc2-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jan 2013 10:29:51 -0800 X-EIP: [M0gT2JlEzhIty41bMm+rI+pAJ+RPPX09] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_e0990674-0897-45dc-bae4-12073b125aeb_" From: Bernard Aboba To: Alan DeKok Date: Fri, 4 Jan 2013 10:29:51 -0800 Importance: Normal In-Reply-To: <50E7186C.7000708@freeradius.org> References: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com>, , <50E7186C.7000708@freeradius.org> MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jan 2013 18:29:51.0388 (UTC) FILETIME=[7BF8ADC0:01CDEAA9] Cc: Sam Hartman , Jim Schaad , "radext@ietf.org" Subject: Re: [radext] Comments on draft-ietf-radext-nai-00 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, 04 Jan 2013 18:29:52 -0000 --_e0990674-0897-45dc-bae4-12073b125aeb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The NAI has been around for a decade. What the heck is the issue with ju= st using it? [BA] The NAI definition in RFC 2486 and 4282 applies to network access (PPP= =2C EAP=2C etc.). Since network access was the only application of RADIUS= at the time those documents were written=2C it could be assumed that the R= ADIUS User-Name Attribute also contained an NAI.=20 However=2C where RADIUS is used for application-layer authentication (e.g. = in SIP or HTTP)=2C it isn't clear to me that the User-Name will necessaril= y contain an NAI=2C or that statements about normalization will necessarily= apply.=20 For example=2C can RADEXT impose a normalization requirement on SIP UACs?=20 = --_e0990674-0897-45dc-bae4-12073b125aeb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B The NAI has been around f= or a decade. What the heck is the issue with just using it?

[B= A] The NAI definition in RFC 2486 and 4282 applies to network access (PPP= =2C EAP=2C etc.). =3B =3B Since network access was the only applica= tion of RADIUS at the time those documents were written=2C it could be assu= med that the RADIUS User-Name Attribute also contained an NAI.

Howe= ver=2C where RADIUS is used for application-layer authentication (e.g. in S= IP or HTTP)=2C =3B it isn't clear to me that the User-Name will necessa= rily contain an NAI=2C or that statements about normalization will necessar= ily apply.

For example=2C can RADEXT impose a normalization require= ment on SIP UACs?


= --_e0990674-0897-45dc-bae4-12073b125aeb_-- From ietf@augustcellars.com Fri Jan 4 10:54:47 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E43021F881C for ; Fri, 4 Jan 2013 10:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 L2bHNJ8-Q8Ia for ; Fri, 4 Jan 2013 10:54:47 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B26721F87ED for ; Fri, 4 Jan 2013 10:54:34 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id A2A452C9EE; Fri, 4 Jan 2013 10:54:33 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" References: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com> In-Reply-To: Date: Fri, 4 Jan 2013 10:54:12 -0800 Message-ID: <00dd01cdeaac$e3bbe9b0$ab33bd10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJavyr52TFlTL/rQumzVqKUD68BqgEtBa2AlxZzESA= Content-Language: en-us Cc: radext@ietf.org, 'Alan DeKok' Subject: Re: [radext] Comments on draft-ietf-radext-nai-00 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, 04 Jan 2013 18:54:47 -0000 Sam, This text is in the context of RADIUS limitations. It says that for Diameter the length limitation is much longer Jim > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Friday, January 04, 2013 5:20 AM > To: Jim Schaad > Cc: Alan DeKok; radext@ietf.org > Subject: Re: [radext] Comments on draft-ietf-radext-nai-00 > > >>>>> "Jim" == Jim Schaad writes: > > Jim> In section 2.3, is there still an absolute limit to the length > Jim> of the NAI with the possibility of using the Radius > Jim> fragmentation draft to extend them longer? While it would not > Jim> be generally reasonable, it might remove the restriction. > > > More generally, to what extent is NAI a RADIUS concept and to what extent > is it an AAA concept and potentially broader. > Perhaps it's better to say that NAIs that MAY be transported over RADIUS > have this limitation? From aland@deployingradius.com Fri Jan 4 12:28:51 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2223B21F8869 for ; Fri, 4 Jan 2013 12:28:51 -0800 (PST) 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 QkV-x1oVQMlW for ; Fri, 4 Jan 2013 12:28:50 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 33EC721F8860 for ; Fri, 4 Jan 2013 12:28:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 4C1CB2243693 for ; Fri, 4 Jan 2013 21:27:59 +0100 (CET) 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 n2iZOYEMV80A for ; Fri, 4 Jan 2013 21:27:56 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 829CC224367A for ; Fri, 4 Jan 2013 21:27:56 +0100 (CET) Message-ID: <50E73B4B.80902@deployingradius.com> Date: Fri, 04 Jan 2013 15:27:55 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "radext@ietf.org" References: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com>, In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [radext] Comments on draft-ietf-radext-nai-00 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, 04 Jan 2013 20:28:51 -0000 Bernard Aboba wrote: > [BA] This raises the question of what the definition of NAI is for the > purpose of this document. Perhaps it's becoming more of an authorization identifier. > I am not sure that the above definition is still usable, because since RFC 4282 was published, RADIUS has been > extended to handle authentication for more than just network access. For example, RFC 5090 defines how to use > RADIUS for Digest Authentication (HTTP, SIP, etc.) I think it's a less useful definition. > As a result, is it still valid to assume that the RADIUS User-Name Attribute contains an NAI? I think so. It's widely used that way in practice. > For example, RFC 5090 Section 2.2.1 includes the following statement: > > Correlation between User-Name and SIP-AOR AVP values is required just > to avoid any user from registering or misusing a SIP-AOR that has > been allocated to a different user. > > In the above statement, it would appear that the RADIUS User-Name Attribute is to be "correlated" with the SIP AOR. Which gets into all kinds of issues. I18n, among others. The RFC 5090 comment about correlation seems to me like they've punted on interoperability issues. If the identities are the same, then there should ideally be only one, or they should be required to be identical. If the identities are different, then "correlation" would need to be well-defined. > Does the ABNF provided in this document apply to the contents of the RADIUS User-Name in this case? Is a User-Name Attribute > "correlated" with a SIP AOR an NAI? I would say "yes" to the first one, and "not my problem" to the second one. The NAI has been around for a decade. What the heck is the issue with just using it? Alan DeKok. From aland@deployingradius.com Fri Jan 4 12:34:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF10D21F88B2 for ; Fri, 4 Jan 2013 12:34:49 -0800 (PST) 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 kPeS4GdCCook for ; Fri, 4 Jan 2013 12:34:49 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA0E21F88DD for ; Fri, 4 Jan 2013 12:34:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8183E2243693; Fri, 4 Jan 2013 21:34:48 +0100 (CET) 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 bObvOMtpmhrm; Fri, 4 Jan 2013 21:34:46 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id BDF43224367A; Fri, 4 Jan 2013 21:34:45 +0100 (CET) Message-ID: <50E73CE4.9080000@deployingradius.com> Date: Fri, 04 Jan 2013 15:34:44 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com>, , <50E7186C.7000708@freeradius.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , Jim Schaad , "radext@ietf.org" Subject: Re: [radext] Comments on draft-ietf-radext-nai-00 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, 04 Jan 2013 20:34:50 -0000 Bernard Aboba wrote: > [BA] The NAI definition in RFC 2486 and 4282 applies to network access > (PPP, EAP, etc.). Since network access was the only application of > RADIUS at the time those documents were written, it could be assumed > that the RADIUS User-Name Attribute also contained an NAI. Sure. > However, where RADIUS is used for application-layer authentication (e.g. > in SIP or HTTP), it isn't clear to me that the User-Name will > necessarily contain an NAI, or that statements about normalization will > necessarily apply. That is likely true. > For example, can RADEXT impose a normalization requirement on SIP UACs? I would say no. But if the SIP credentials go into a RADIUS packet, I would *hope* that the two standards are compatible. The expectation of the end user is that they have a "username" and "password" which is tied to their identity. It is *not* tied to the individual protocol used. The user may not even know *which* protocol is being used for network or application access. I see us having two choices (1) give up on the problem, and say that *every* protocol has unique user identifiers which have *no* meaning outside of that protocol. Or (2) try to meet the end user expectations where identities are across protocols. Here, if the SIP UAC is gratuitously different from the common RADIUS practice, then SIP would seem to be incompatible with RADIUS authentication. If they're similar, then the common practice would be to use the *subset* of identifiers that are acceptable to both protocols. My $0.02 is that an authentication protocol should define a standard format for identifiers. We should encourage other working groups to use that standard. Alan DeKok. From aland@deployingradius.com Fri Jan 4 17:46:10 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0F721F8A5A for ; Fri, 4 Jan 2013 17:46:10 -0800 (PST) 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 RieiENqtg5Bg for ; Fri, 4 Jan 2013 17:46:09 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1D9C21F88CB for ; Fri, 4 Jan 2013 17:46:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 5F69422436A4; Sat, 5 Jan 2013 02:45:16 +0100 (CET) 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 a4OsyyApXtHg; Sat, 5 Jan 2013 02:45:14 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id E7DC92243693; Sat, 5 Jan 2013 02:45:13 +0100 (CET) Message-ID: <50E785A8.7090500@deployingradius.com> Date: Fri, 04 Jan 2013 20:45:12 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com> In-Reply-To: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Comments on draft-ietf-radext-nai-00 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: Sat, 05 Jan 2013 01:46:10 -0000 Jim Schaad wrote: > In section 2.3, is there still an absolute limit to the length of the NAI > with the possibility of using the Radius fragmentation draft to extend them > longer? While it would not be generally reasonable, it might remove the > restriction. The fragmentation draft applies to the "long" extended attributes. So new attributes can have a long NAI. The User-Name is still limited to 253 octets. It may be worth adding a note that other protocols have other limitations. > In Section 2.11, Given the potential registration of new top level domains, > do you still want to keep fred@example as an invalid NAI? What if somebody > succeeds in getting example as a top level domain? (Which I sincerely hope > could never happen.) The ABNF says: > In Section 2.7, Two issues: > a) I am unclear if one should do the comparison and routing based on the > entire utf8-realm portion of the name, or if one can (and perhaps should be > able to) do the routing based on the set of labels that occur in the > utf8-realm. As part of this one wonders about doing any matching of > utf8-realm names and if that needs to be discussed as well > > b) I find the last paragraph to be very confusing. The use of or would > make it appear that it would be one of the items listed, however based on > what I would expect it could be any or all of the elements listed. > Grammatically this is very fuzzy. Additionally, do you want to pre-view > section 2.9 and make the DNS Host name be an explicit ASCII version of the > DNS host name rather than allowing people to think it might be the > internalized version? > > Jim > > > From aland@deployingradius.com Fri Jan 4 17:57:00 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7477921F854D for ; Fri, 4 Jan 2013 17:57:00 -0800 (PST) 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 4aKgPdJclHB8 for ; Fri, 4 Jan 2013 17:56:59 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB5221F854E for ; Fri, 4 Jan 2013 17:56:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 3F6D322436A4; Sat, 5 Jan 2013 02:56:27 +0100 (CET) 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 YFIaQyDcA9au; Sat, 5 Jan 2013 02:56:26 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 71C142243693; Sat, 5 Jan 2013 02:56:26 +0100 (CET) Message-ID: <50E78849.70603@deployingradius.com> Date: Fri, 04 Jan 2013 20:56:25 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com> In-Reply-To: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Comments on draft-ietf-radext-nai-00 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: Sat, 05 Jan 2013 01:57:00 -0000 Jim Schaad wrote: > In section 2.3, is there still an absolute limit to the length of the NAI > with the possibility of using the Radius fragmentation draft to extend them > longer? While it would not be generally reasonable, it might remove the > restriction. The fragmentation draft applies to the "long" extended attributes. So new attributes can have a long NAI. The User-Name is still limited to 253 octets. It may be worth adding a note that other protocols have other limitations. > In Section 2.11, Given the potential registration of new top level domains, > do you still want to keep fred@example as an invalid NAI? What if somebody > succeeds in getting example as a top level domain? (Which I sincerely hope > could never happen.) The ABNF says: utf8-realm = 1*( label "." ) label So the issue is with the lack of a '.', not the "example" TLD. > In Section 2.7, Two issues: > a) I am unclear if one should do the comparison and routing based on the > entire utf8-realm portion of the name, or if one can (and perhaps should be > able to) do the routing based on the set of labels that occur in the > utf8-realm. As part of this one wonders about doing any matching of > utf8-realm names and if that needs to be discussed as well I would suggest that routing be done on the entirety of the utf8-realm. That's the easiest process to follow. I'll add some text suggesting that routing can be done on labels, too. But it should again be done as binary comparison: ... It is RECOMMENDED to use the entirety of the "utf8-realm" for the routing decisions. However, systems MAY use a portion of the "utf8-realm" portion, so long as that portion is a valid "utf8-realm", and that portion is handled as above. For example, routing "fred@example.com" to a "com" destination is forbidden, because "com" is not a valid "utf8-realm". However, routing "fred@sales.example.com" to the "example.com" destination is permissible. ... > b) I find the last paragraph to be very confusing. The use of or would > make it appear that it would be one of the items listed, however based on > what I would expect it could be any or all of the elements listed. > Grammatically this is very fuzzy. OK. I'll clarify that: This "next hop" information may be any of, or all of, the following information: IP address; port; RADIUS shared secret; TLS certificate; DNS host name; or instruction to use dyanmic DNS discovery (i.e. look up a record in the "utf8-realm" domain) > Additionally, do you want to pre-view > section 2.9 and make the DNS Host name be an explicit ASCII version of the > DNS host name rather than allowing people to think it might be the > internalized version? I'd prefer to avoid that issue, if possible. A statically configured DNS host name should be in a form that's acceptable to all parties, and works. It only needs to be an ASCII version if the i18n version is non-normalized, and the parties can't for normalization / ASCII conversion. The goal of modern DNS systems would seem to be to allow i18n domains, so we should allow that, too. Alan DeKok. From trac+radext@trac.tools.ietf.org Fri Jan 4 18:26:51 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FF721F86B3 for ; Fri, 4 Jan 2013 18:26:51 -0800 (PST) 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 IaQahLhmWT66 for ; Fri, 4 Jan 2013 18:26:50 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7A821F85CB for ; Fri, 4 Jan 2013 18:26:48 -0800 (PST) Received: from localhost ([127.0.0.1]:53146 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TrJT8-0004hX-Mv; Sat, 05 Jan 2013 03:26:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: aland@deployingradius.com X-Trac-Project: radext Date: Sat, 05 Jan 2013 02:26:42 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/144#comment:1 Message-ID: <081.5162f4f07c108b9588070cd48b07522d@trac.tools.ietf.org> References: <066.415fcb8c259c89020f2bcba954e31bb7@trac.tools.ietf.org> X-Trac-Ticket-ID: 144 In-Reply-To: <066.415fcb8c259c89020f2bcba954e31bb7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: 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 Cc: radext@ietf.org Subject: Re: [radext] #144: Definition of NAI 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: Sat, 05 Jan 2013 02:26:51 -0000 #144: Definition of NAI Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: 1) I would prefer to define the NAI as a user identifier. i.e. it has a definition *before* any protocol-specific escaping. 2) likely not. Perhaps "inter-domain authentication" instead of "roaming" would be better. Examples of roaming are widely known, and can likely be removed from the abstract. It then becomes: ... In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each others users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing network resources. This document is a revised version of RFC 4282 [RFC4282], which addresses issues with international character sets, as well as a number of other corrections to the previous document. ... 3) I'd prefer to talk about "the NAI". Protocols that use their own encoding are unlikely to inter-operate with AAA systems. I'd suggest adding a new section "use in other protocols": ... As noted earlier, the NAI MAY be used in other, non-AAA protocols. It is RECOMMENDED that the definition given here be used unchanged. Using other definitions for user identifiers may hinder inter-operability, and the users ability to authenticate successfully. Where other protocols are not 8-bit clean, any transport layer MUST NOT affect the definition or handling of the NAI. That is, if a protocol escapes the '.' character as "%2E", then a string may be transported as "fred@example%2Ecom", whereas the NAI for that user is "fred@example.com". ... -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | aland@deployingradius.com Type: defect | Status: closed Priority: critical | Milestone: milestone1 Component: RFC4282bis | Version: 1.0 Severity: Candidate WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From aland@freeradius.org Fri Jan 4 09:59:16 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93A021F87CC for ; Fri, 4 Jan 2013 09:59:16 -0800 (PST) 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 MPvqse9skqUK for ; Fri, 4 Jan 2013 09:59:16 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 34E0521F86DC for ; Fri, 4 Jan 2013 09:59:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 05AC02243693; Fri, 4 Jan 2013 18:59:13 +0100 (CET) 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 u3UJUPo5Ajlp; Fri, 4 Jan 2013 18:59:10 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 391BC224367A; Fri, 4 Jan 2013 18:59:10 +0100 (CET) Message-ID: <50E7186C.7000708@freeradius.org> Date: Fri, 04 Jan 2013 12:59:08 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com>, In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 05 Jan 2013 05:37:47 -0800 Cc: Sam Hartman , Jim Schaad , "radext@ietf.org" Subject: Re: [radext] Comments on draft-ietf-radext-nai-00 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, 04 Jan 2013 17:59:16 -0000 Bernard Aboba wrote: > [BA] This raises the question of what the definition of NAI is for the > purpose of this document. Perhaps it's becoming more of an authorization identifier. > I am not sure that the above definition is still usable, because since RFC 4282 was published, RADIUS has been > extended to handle authentication for more than just network access. For example, RFC 5090 defines how to use > RADIUS for Digest Authentication (HTTP, SIP, etc.) I think it's a less useful definition. > As a result, is it still valid to assume that the RADIUS User-Name Attribute contains an NAI? I think so. It's widely used that way in practice. > For example, RFC 5090 Section 2.2.1 includes the following statement: > > Correlation between User-Name and SIP-AOR AVP values is required just > to avoid any user from registering or misusing a SIP-AOR that has > been allocated to a different user. > > In the above statement, it would appear that the RADIUS User-Name Attribute is to be "correlated" with the SIP AOR. Which gets into all kinds of issues. I18n, among others. The RFC 5090 comment about correlation seems to me like they've punted on interoperability issues. If the identities are the same, then there should ideally be only one, or they should be required to be identical. If the identities are different, then "correlation" would need to be well-defined. > Does the ABNF provided in this document apply to the contents of the RADIUS User-Name in this case? Is a User-Name Attribute > "correlated" with a SIP AOR an NAI? I would say "yes" to the first one, and "not my problem" to the second one. The NAI has been around for a decade. What the heck is the issue with just using it? Alan DeKok. From hartmans@painless-security.com Mon Jan 7 05:38:06 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48ECA21F862D for ; Mon, 7 Jan 2013 05:38:06 -0800 (PST) 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 m3JkT2V3EmRw for ; Mon, 7 Jan 2013 05:38:03 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D5DA621F85DF for ; Mon, 7 Jan 2013 05:38:01 -0800 (PST) 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 BE5C120144; Mon, 7 Jan 2013 08:31:34 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 23AD943F0; Mon, 7 Jan 2013 08:34:30 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com> <50E7186C.7000708@freeradius.org> <50E73CE4.9080000@deployingradius.com> Date: Mon, 07 Jan 2013 08:34:30 -0500 In-Reply-To: <50E73CE4.9080000@deployingradius.com> (Alan DeKok's message of "Fri, 04 Jan 2013 15:34:44 -0500") 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: Bernard Aboba , "radext@ietf.org" , Jim Schaad Subject: Re: [radext] Comments on draft-ietf-radext-nai-00 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, 07 Jan 2013 13:38:07 -0000 I think it is strongly desirable that we say the username attribute always contains a NAI. I think this is close enough to true for SIP and HTTP and is definitely what ABFAB needs. I think that if we do anything else proxies need to know far more about the application than is desirable. In my mind one major advantage of RADIUS over Diameter is that RADIUS doesn't have applications. It's also a disadvantage if you need that complexity. --Sam From stefan.winter@restena.lu Mon Jan 7 06:10:29 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C84021F87DC for ; Mon, 7 Jan 2013 06:10:29 -0800 (PST) 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 5tu37PmTsr2b for ; Mon, 7 Jan 2013 06:10:28 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id AB07021F8619 for ; Mon, 7 Jan 2013 06:10:28 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 203E610583 for ; Mon, 7 Jan 2013 15:10:27 +0100 (CET) Received: from [IPv6:2001:a18:1:8:b1e1:905:ba13:1d87] (unknown [IPv6:2001:a18:1:8:b1e1:905:ba13:1d87]) by smtprelay.restena.lu (Postfix) with ESMTPS id 130611057E for ; Mon, 7 Jan 2013 15:10:27 +0100 (CET) Message-ID: <50EAD74D.2080308@restena.lu> Date: Mon, 07 Jan 2013 15:10:21 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: radext@ietf.org References: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com> <50E7186C.7000708@freeradius.org> <50E73CE4.9080000@deployingradius.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig401A4DF34464CCEDDBD24BB0" X-Virus-Scanned: ClamAV Subject: Re: [radext] Comments on draft-ietf-radext-nai-00 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, 07 Jan 2013 14:10:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig401A4DF34464CCEDDBD24BB0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I think it is strongly desirable that we say the username attribute > always contains a NAI. Very often, the User-Name attribute is constructed from outside of RADIUS, and often by direct user input. E.g. for EAP passthrough authenticators, where the RADIUS client has no chance but to literally copy whatever it got as EAP-Respsonse/Identity. And users are creative. It is very difficult to enforce "User-Name always contains a NAI". It would basically boil down to enforce on every RADIUS-backed application that it refuses to accept user input which is not a valid NAI. In the example above, the EAP supplicant would need to stop the user from trying to fill in a non-NAI identifier into the "Username" box. I believe RADIUS will always have to cope with contents of User-Name which are not valid NAIs. Maybe "cope with" can turn out to mean "reject" or "silently discard". But if that's supposed to be the case for all incoming User-Names, irrespective of the deployment, the document would need to state this very explicitly (and I didn't find that yet). Greetings, Stefan Winter > I think this is close enough to true for SIP and HTTP and is definitely= > what ABFAB needs. > I think that if we do anything else proxies need to know far more about= > the application than is desirable. > In my mind one major advantage of RADIUS over Diameter is that RADIUS > doesn't have applications. > It's also a disadvantage if you need that complexity. >=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 --------------enig401A4DF34464CCEDDBD24BB0 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 undefined - http://www.enigmail.net/ iEYEARECAAYFAlDq11IACgkQ+jm90f8eFWbmuwCfT2oN1NAKi4pniAqT2wrXa7Mm yhcAnR7Y/CYckdCe5tXHc5zG7lqbOiXb =opZU -----END PGP SIGNATURE----- --------------enig401A4DF34464CCEDDBD24BB0-- From aland@deployingradius.com Mon Jan 7 07:00:23 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3651321F88AE for ; Mon, 7 Jan 2013 07:00:23 -0800 (PST) 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 765TMIY1FWOX for ; Mon, 7 Jan 2013 07:00:22 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id A229C21F8812 for ; Mon, 7 Jan 2013 07:00:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 9646F2240CAA; Mon, 7 Jan 2013 16:00:20 +0100 (CET) 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 blC927d62ltM; Mon, 7 Jan 2013 16:00:18 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 22F372240C42; Mon, 7 Jan 2013 16:00:18 +0100 (CET) Message-ID: <50EAE300.4050404@deployingradius.com> Date: Mon, 07 Jan 2013 10:00:16 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <00a501cdea30$ae46fcb0$0ad4f610$@augustcellars.com> <50E7186C.7000708@freeradius.org> <50E73CE4.9080000@deployingradius.com> <50EAD74D.2080308@restena.lu> In-Reply-To: <50EAD74D.2080308@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Comments on draft-ietf-radext-nai-00 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, 07 Jan 2013 15:00:23 -0000 Stefan Winter wrote: > It is very difficult to enforce "User-Name always contains a NAI". It > would basically boil down to enforce on every RADIUS-backed application > that it refuses to accept user input which is not a valid NAI. In the > example above, the EAP supplicant would need to stop the user from > trying to fill in a non-NAI identifier into the "Username" box. Sure. RADIUS already has many cases where the User-Name doesn't contain an NAI. We can't *require* it to be an NAI. We can, however, RECOMMEND it. And similarly recommend that other protocols use it. Again, having each protocol invent a user identifier is *ridiculous*. It's 2013. Many protocols back-end into AAA systems already. So if the identifier is going to be used in RADIUS with roaming, just make the identifier an NAI. Don't try to be smart and invent something incompatible. > I believe RADIUS will always have to cope with contents of User-Name > which are not valid NAIs. Maybe "cope with" can turn out to mean > "reject" or "silently discard". But if that's supposed to be the case > for all incoming User-Names, irrespective of the deployment, the > document would need to state this very explicitly (and I didn't find > that yet). I strongly oppose any suggestion to say "the User-Name MUST contain an NAI". This document defines the NAI, and suggests how it is used in other protocols. It adds *no* normative requirements to RADIUS. Alan DeKok. From internet-drafts@ietf.org Tue Jan 8 05:41:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C12F21F8475; Tue, 8 Jan 2013 05:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 nAEEN3YDatCn; Tue, 8 Jan 2013 05:41:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC23021F8477; Tue, 8 Jan 2013 05:41:48 -0800 (PST) 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.37 Message-ID: <20130108134148.24199.54857.idtracker@ietfa.amsl.com> Date: Tue, 08 Jan 2013 05:41:48 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-nai-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, 08 Jan 2013 13:41:49 -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 : The Network Access Identifier Author(s) : Alan DeKok Filename : draft-ietf-radext-nai-01.txt Pages : 20 Date : 2013-01-08 Abstract: In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each others users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing network resources. This document is a revised version of RFC 4282 [RFC4282], which addresses issues with international character sets, as well as a number of other corrections to the previous document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-nai There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-nai-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-nai-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From aland@deployingradius.com Tue Jan 8 05:44:07 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFC521F84E6 for ; Tue, 8 Jan 2013 05:44:06 -0800 (PST) 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 mfN4yw2qYp5m for ; Tue, 8 Jan 2013 05:44:06 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 674AC21F8475 for ; Tue, 8 Jan 2013 05:44:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id C38222241BAE for ; Tue, 8 Jan 2013 14:43:18 +0100 (CET) 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 rWcRLozJfLtG for ; Tue, 8 Jan 2013 14:43:17 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id E658A2241A40 for ; Tue, 8 Jan 2013 14:43:16 +0100 (CET) Message-ID: <50EC2277.5010404@deployingradius.com> Date: Tue, 08 Jan 2013 08:43:19 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "radext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [radext] Updated NAI document 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, 08 Jan 2013 13:44:07 -0000 I've just posted the updated NAI document. It addresses all concerns raised here, and in the issues tracker. If there are no further issues with it, we should be able to last-call it. Alan DeKok. From internet-drafts@ietf.org Tue Jan 8 05:48:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB68221F8727; Tue, 8 Jan 2013 05:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 wydMne+o0PhJ; Tue, 8 Jan 2013 05:48:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D72621F8739; Tue, 8 Jan 2013 05:48:49 -0800 (PST) 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.37 Message-ID: <20130108134849.24226.60186.idtracker@ietfa.amsl.com> Date: Tue, 08 Jan 2013 05:48:49 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-extensions-08.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, 08 Jan 2013 13:48:50 -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 : Remote Authentication Dial In User Service (RADIUS) Prot= ocol Extensions Author(s) : Alan DeKok Avi Lior Filename : draft-ietf-radext-radius-extensions-08.txt Pages : 66 Date : 2013-01-08 Abstract: The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-radius-extensions-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-radius-extensions-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From aland@deployingradius.com Tue Jan 8 05:56:42 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF2C21F8837 for ; Tue, 8 Jan 2013 05:56:42 -0800 (PST) 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 uROPFW8yCOSE for ; Tue, 8 Jan 2013 05:56:41 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 772FA21F87AD for ; Tue, 8 Jan 2013 05:56:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 13C972241BAE for ; Tue, 8 Jan 2013 14:56:41 +0100 (CET) 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 d1fbZuUDOahy for ; Tue, 8 Jan 2013 14:56:40 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 44DC52241A40 for ; Tue, 8 Jan 2013 14:56:40 +0100 (CET) Message-ID: <50EC259A.6080400@deployingradius.com> Date: Tue, 08 Jan 2013 08:56:42 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "radext@ietf.org" References: <20130108134849.24226.60186.idtracker@ietfa.amsl.com> In-Reply-To: <20130108134849.24226.60186.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [radext] I-D Action: draft-ietf-radext-radius-extensions-08.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, 08 Jan 2013 13:56:42 -0000 This draft addresses all open issues. There will likely be more feedback as part of the IETF LC process. They will be added to the document in a subsequent revision. For now, it seemed prudent to have a "clean" version of the document, with no outstanding issues. internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the RADIUS EXTensions Working Group of the IETF. > > Title : Remote Authentication Dial In User Service (RADIUS) Protocol Extensions > Author(s) : Alan DeKok > Avi Lior > Filename : draft-ietf-radext-radius-extensions-08.txt > Pages : 66 > Date : 2013-01-08 > > Abstract: > The Remote Authentication Dial In User Service (RADIUS) protocol is > nearing exhaustion of its current 8-bit Attribute Type space. In > addition, experience shows a growing need for complex grouping, along > with attributes which can carry more than 253 octets of data. This > document defines changes to RADIUS which address all of the above > problems. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-radius-extensions-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-extensions-08 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From bernard_aboba@hotmail.com Tue Jan 8 05:57:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D536E21F876E for ; Tue, 8 Jan 2013 05:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 k+1HNSU6Q5dM for ; Tue, 8 Jan 2013 05:57:49 -0800 (PST) Received: from blu0-omc2-s28.blu0.hotmail.com (blu0-omc2-s28.blu0.hotmail.com [65.55.111.103]) by ietfa.amsl.com (Postfix) with ESMTP id 1B78F21F8758 for ; Tue, 8 Jan 2013 05:57:49 -0800 (PST) Received: from BLU002-W95 ([65.55.111.72]) by blu0-omc2-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jan 2013 05:57:48 -0800 X-EIP: [CJUciYf+nb+YVuU9Ne9YKCK7q6VPRVut] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_ea9756db-7f64-4562-9a44-dd81eff16783_" From: Bernard Aboba To: Alan DeKok , "radext@ietf.org" Date: Tue, 8 Jan 2013 05:57:48 -0800 Importance: Normal In-Reply-To: <50EC2277.5010404@deployingradius.com> References: <50EC2277.5010404@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jan 2013 13:57:48.0311 (UTC) FILETIME=[244FCA70:01CDEDA8] Subject: Re: [radext] Updated NAI document 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, 08 Jan 2013 13:57:49 -0000 --_ea9756db-7f64-4562-9a44-dd81eff16783_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looking at the revision=2C it appears that many of the issues remain open. = Can you post what the proposed resolutions? > Date: Tue=2C 8 Jan 2013 08:43:19 -0500 > From: aland@deployingradius.com > To: radext@ietf.org > Subject: [radext] Updated NAI document >=20 > I've just posted the updated NAI document. It addresses all concerns > raised here=2C and in the issues tracker. >=20 > If there are no further issues with it=2C we should be able to last-cal= l it. >=20 > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext = --_ea9756db-7f64-4562-9a44-dd81eff16783_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Looking at the revision=2C it ap= pears that many of the issues remain open. Can you post what the proposed r= esolutions?

>=3B Date: = Tue=2C 8 Jan 2013 08:43:19 -0500
>=3B From: aland@deployingradius.com<= br>>=3B To: radext@ietf.org
>=3B Subject: [radext] Updated NAI docum= ent
>=3B
>=3B I've just posted the updated NAI document. It a= ddresses all concerns
>=3B raised here=2C and in the issues tracker.>=3B
>=3B If there are no further issues with it=2C we should b= e able to last-call it.
>=3B
>=3B Alan DeKok.
>=3B ______= _________________________________________
>=3B radext mailing list
= >=3B radext@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/rade= xt
= --_ea9756db-7f64-4562-9a44-dd81eff16783_-- From bclaise@cisco.com Tue Jan 8 06:05:25 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14E921F89CB; Tue, 8 Jan 2013 06:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.369 X-Spam-Level: X-Spam-Status: No, score=-10.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 FGXPuM9tBTEw; Tue, 8 Jan 2013 06:05:25 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 38F2F21F89C0; Tue, 8 Jan 2013 06:05:25 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r08E5ORe008437; Tue, 8 Jan 2013 15:05:24 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r08E5Nr2005436; Tue, 8 Jan 2013 15:05:23 +0100 (CET) Message-ID: <50EC27A3.3070705@cisco.com> Date: Tue, 08 Jan 2013 15:05:23 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: ietf@ietf.org References: <20130104143514.20728.47886.idtracker@ietfa.amsl.com> In-Reply-To: <20130104143514.20728.47886.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, The IESG , IETF-Announce Subject: Re: [radext] Last Call: (Remote Authentication Dial In User Service (RADIUS) Protocol Extensions) to Proposed Standard 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, 08 Jan 2013 14:05:26 -0000 Dear all, Please note that version 8 has just been posted. Regards, Benoit > The IESG has received a request from the RADIUS EXTensions WG (radext) to > consider the following document: > - 'Remote Authentication Dial In User Service (RADIUS) Protocol > Extensions' > 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 2013-01-18. 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 > > > The Remote Authentication Dial In User Service (RADIUS) protocol is > nearing exhaustion of its current 8-bit Attribute Type space. In > addition, experience shows a growing need for complex grouping, along > with attributes which can carry more than 253 octets of data. This > document defines changes to RADIUS which address all of the above > problems. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > From aland@deployingradius.com Tue Jan 8 06:17:36 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893DF21F8671 for ; Tue, 8 Jan 2013 06:17:36 -0800 (PST) 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 8XhC+x2V0hEk for ; Tue, 8 Jan 2013 06:17:35 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 418E321F8750 for ; Tue, 8 Jan 2013 06:17:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 0D84F2241BAE; Tue, 8 Jan 2013 15:17:28 +0100 (CET) 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 4l6w3IKh0Fob; Tue, 8 Jan 2013 15:17:27 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 0D8E32241A40; Tue, 8 Jan 2013 15:17:26 +0100 (CET) Message-ID: <50EC2A79.7090505@deployingradius.com> Date: Tue, 08 Jan 2013 09:17:29 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <50EC2277.5010404@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Updated NAI document 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, 08 Jan 2013 14:17:36 -0000 Bernard Aboba wrote: > Looking at the revision, it appears that many of the issues remain open. Hm... I don't see that. The diff is here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-01.txt There were a number of changes to the docuemnt. > Can you post what the proposed resolutions? I posted all of the proposed text to the list. Here again for summary: * "roaming / NAI" in abstract and introduction ** changed text to use "inter-domain authentication" ** removed text around "ISPs" etc. in abstract: Abstract: In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each others users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing network resources. This document is a revised version of RFC 4282 [RFC4282], which addresses issues with international character sets, as well as a number of other corrections to the previous document. * for SIP / HTTP, etc. added text in the introduction on "interested parties": * Other protocols which are interested in leveraging the users credentials in order to take advantage of an existing authentication framework. * definitions of "local" text in Terminology section: "local" or "localized" text Text which is either in non-UTF-8, or in non-normalized form. The character set, encoding, and locale are (in general) unknown to Authentication, Authorization, and Accounting (AAA) network protocols. * for other protocols, added text in Purpose section: We also hope that other protocols can take advantage of the NAI. Many protocols include authentication capabilities. The authentication credentials supplied in those protocols can end up being transported in AAA protocols. It is therefore useful to define a representation of the user credentials which can be shared across multiple protocols. * in "Motivation", added note: o The [RFC4282] ABNF is not aligned with internationalization of DNS. * updated terminology when recommending NFC: See [RFC5198] for a discussion of normalization; the use of Normal Form Composed (NFC) is RECOMMENDED. * Noted difference between octet and character counts in NAI length: * NAI octet length constraints may impose a more severe constraint on the number of UTF-8 characters. * noted protocol-specific limitations on NAI length: * NAIs may be transported in other protocols. Each protocol can have its own limitations on maximum NAI length. * permitted use of "anonymous@realm": ... single user. However, current practice is to use the username "anonymous" instead of omitting the username part. This behavior is also permitted. * Updated Section 2.6 (Normalization process) with suggested text on EAP && proxies, as posted to the list * Added Section 2.7, "Use in Other Protocols", which discusses the use of the NAI in other protocols. It addresses the concerns raised here, and makes suggestions for best practices * Clarified suggested data for "next hop" routing information. It can be any / all of (IP, port, host name, certificate, etc.) * noted that routing on portions of the NAI is explicitly permitted, so long as that portion of the NAI is a valid realm. Example of routing fred@sales.example.com to "com" is not allowed, but routing to "example.com" is allowed * Changes to Section 2.10 (compatibility with DNS), using text as posted to the list. (refer to API, not library, etc.) * removed text suggesting that differences between EAP Identity and User-Name are problematic * moved various RFCs to normative reference, as per Benoit's suggestion From aland@deployingradius.com Tue Jan 8 06:32:52 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E25D21F873B for ; Tue, 8 Jan 2013 06:32:52 -0800 (PST) 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 tgIqwrT434wc for ; Tue, 8 Jan 2013 06:32:52 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9E5921F867A for ; Tue, 8 Jan 2013 06:32:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id DF0D72241C9F; Tue, 8 Jan 2013 15:32:50 +0100 (CET) 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 ogm4mCj9RnCT; Tue, 8 Jan 2013 15:32:50 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id EF6162241BAE; Tue, 8 Jan 2013 15:32:49 +0100 (CET) Message-ID: <50EC2E14.2050903@deployingradius.com> Date: Tue, 08 Jan 2013 09:32:52 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <50EC2277.5010404@deployingradius.com> <50EC2A79.7090505@deployingradius.com> In-Reply-To: <50EC2A79.7090505@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Updated NAI document 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, 08 Jan 2013 14:32:52 -0000 Alan DeKok wrote: > Bernard Aboba wrote: >> Looking at the revision, it appears that many of the issues remain open. > > Hm... I don't see that. The diff is here: Reviewing the issues tracker, there are two remaining issues: 145 - realms allowed by the ABNF can not always be registered in DNS This is already covered in Section 2.5: o Realms MUST be of the form that can be registered as a Fully Qualified Domain Name (FQDN) within the DNS. This point could be made clearer, but I think the issue is covered by the existing text. Perhaps re-stating that requirement in the introduction, so people don't miss it? 146 - reference RFC 6365, re: "locale", "normalization", "canonicalization". Possibly. The document references 5198 re: normalization. The document uses "canonicalization" once, and references a "canonical" form multiple times. This canonical form is taken as the "known good" realm data supplied to the interested parties, by the realm owner. So this document does not require that anyone perform "canonicalization" of the realm. The updated Terminology section defines "locale" which seems to agree with RFC 6265, and is good enough for the purposes of this document. I'm open to more upates, of course. I'm not sure I see them as critical at this time. Alan DeKok. From bclaise@cisco.com Fri Jan 11 03:22:38 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B0D21F8873 for ; Fri, 11 Jan 2013 03:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.407 X-Spam-Level: X-Spam-Status: No, score=-10.407 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kobs1TYYF9Ip for ; Fri, 11 Jan 2013 03:22:35 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D8DB721F86EC for ; Fri, 11 Jan 2013 03:22:34 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0BBC4VZ019179; Fri, 11 Jan 2013 12:12:05 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0BBC3OW012956; Fri, 11 Jan 2013 12:12:03 +0100 (CET) Message-ID: <50EFF383.7030108@cisco.com> Date: Fri, 11 Jan 2013 12:12:03 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Wojciech Dec (wdec)" References: <19F346EB777BEE4CB77DA1A2C56F20B3182C82@xmb-aln-x05.cisco.com> In-Reply-To: <19F346EB777BEE4CB77DA1A2C56F20B3182C82@xmb-aln-x05.cisco.com> Content-Type: multipart/alternative; boundary="------------080105060101090106020304" Cc: "radext@ietf.org" , "draft-ietf-radext-ipv6-access@tools.ietf.org" Subject: Re: [radext] Fwd: [OPS-DIR] OPS-DIR Review of draft-ietf-radext-ipv6-access-13 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, 11 Jan 2013 11:22:38 -0000 This is a multi-part message in MIME format. --------------080105060101090106020304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Woj, > Hi All, > > Apologies for not caching this one. For some reason our corporate mail > filter classified messages to the draft-ietf... alias as "Spam". > > I will be posting a ver 14 shortly, however there are two > comments/nits that I need to address here: > > 1. Section 3.4. > > ---snip--- > But there is no mention of how the pool itself is defined. A reference > to the document where this has been specified would be useful > for the reader. > ---snip--- > Reply> Strictly speaking the pool definition is something subject to vendor implementation (as is any of the configuration of Radius too). Having checked some of the other Radius drafts, eg rfc2869, which defines the frame-pool, I did not find descriptive text about how the pool is configured, so it appears ok to leave the text as is. > 2. Non rfc2606 FQDN nit. > TBH I can't find any FQDN that is being used in the text or an explicit IP address, so this seems to be a misinterpretation by the tool of something else. /tmp/draft-ietf-radext-ipv6-access-14.txt(555): Found possible FQDN 'www.iana.org' in position 3; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". --> www.iana.org/assignments/radius-types for the following attributes: However, the text is 6. IANA Considerations This document requires the assignment of five new RADIUS attribute types in the "Radius Types" registry (currently located at http:// www.iana.org/assignments/radius-types for the following attributes: I guess that's fine. Regards, Benoit > Regards, > Woj.. > ------------------------------------------------------------------------ > > * /From/: Benoit Claise > > * /To/: "draft-ietf-radext-ipv6-access at tools.ietf.org > " > > > * /Cc/: "Ersue, Mehmet \(NSN - DE/Munich\)" >, "radext at ietf.org > " > > * /Date/: Tue, 04 Dec 2012 10:56:19 +0100 > * /In-reply-to/: <80A0822C5E9A4440A5117C2F4CD36A640469F0E9 at > DEMUEXC006.nsn-intra.net > > > * /References/: <80A0822C5E9A4440A5117C2F4CD36A640469F0E9 at > DEMUEXC006.nsn-intra.net > > > > ------------------------------------------------------------------------ > Hi Authors, > > Can you please address Mehmet's comments. > > Regards, Benoit > > > -------- Original Message -------- > Subject: [OPS-DIR] OPS-DIR Review of draft-ietf-radext-ipv6-access-13 > Date: Tue, 20 Nov 2012 14:38:15 +0100 > From: Ersue, Mehmet (NSN - DE/Munich) > To: , tools.ietf.org> > > > > I reviewed the draft "RADIUS attributes for IPv6 Access Networks" ( > draft-ietf-radext-ipv6-access-13.txt) for its operational impact. > > Summary: > Intended status: Standards Track > Current status: Waiting for AD Go-Ahead > > The document specifies additional IPv6 RADIUS attributes useful in > residential broadband network deployments, which are: > 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 document follows the standard method for Radius attribute > definition. As such the attributes and their configuration has been > sufficiently described. > > I do not see any blocking issues. The document seems to be ready for > publication as Proposed Standard. > > > Minor issues: > > - Section 4.4. Delegated-IPv6-Prefix-Pool > > I am not a AAA-NAS expert, however section 4.4. defines the > Delegated-IPv6-Prefix-Pool attribute containing the name of an assigned > pool that SHOULD be used to select an IPv6 delegated prefix for the user > on the NAS. But there is no mention of how the pool itself is defined. A > reference to the document where this has been specified would be useful > for the reader. > > > - There is one nit error (lines 453/454) which needs to be fixed: > > ** There are 2 instances of too long lines in the document, the longest > one > being 3 characters in excess of 72. > > > 453 0+ 0+ 0 0 0+ TBA4 > Delegated-IPv6-Prefix-Pool > 454 0+ 0+ 0 0 0+ TBA5 > Stateful-IPv6-Address-Pool > > > - There is one nit warning: > > == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the > document. > > Cheers, > Mehmet > > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR at ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > > > > > > ------------------------------------------------------------------------ > > * Prev by Date: *[radext] Fwd: Gen-art review of > draft-ietf-radext-ipv6-access-13 > * > * Next by Date: *[radext] WG Action: Rechartered RADIUS EXTensions > (radext) > * > * Previous by thread: *[radext] Fwd: Gen-art review of > draft-ietf-radext-ipv6-access-13 > * > * Next by thread: *[radext] WG Action: Rechartered RADIUS EXTensions > (radext) > * > * Index(es): > o *Date* > > > o *Thread* > > > > *Note Well: Messages sent to this mailing list are the opinions of the > senders and do not imply endorsement by the IETF.* > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------080105060101090106020304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Woj,
Hi All,

Apologies for not caching this one. For some reason our corporate mail filter classified messages to the draft-ietf… alias as "Spam".

I will be posting a ver 14 shortly, however there are two comments/nits that I need to address here:

  1. Section 3.4. 
---snip---
But there is no mention of how the pool itself is defined. A reference to the document where this has been specified would be useful
for the reader.
---snip---
Reply> Strictly speaking the pool definition is something subject to vendor implementation (as is any of the configuration of Radius too). Having checked some of the other Radius drafts, eg rfc2869, which defines the frame-pool, I did not find descriptive text about how the pool is configured, so it appears ok to leave the text as is.

          
2. Non rfc2606 FQDN nit.

          
TBH I can't find any FQDN that is being used in the text or an explicit IP address, so this seems to be a misinterpretation by the tool of something else.

          

        

    

    

    
/tmp/draft-ietf-radext-ipv6-access-14.txt(555): Found possible FQDN 'www.iana.org' in position 3; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)".
  -->    www.iana.org/assignments/radius-types for the following attributes:

However, the text is 
6.  IANA Considerations

   This document requires the assignment of five new RADIUS attribute
   types in the "Radius Types" registry (currently located at http://
   www.iana.org/assignments/radius-types for the following attributes:

I guess that's fine.

Regards, Benoit


    

      

          
Regards,

          
Woj..

        
        

        
        

        

          
            

              Hi Authors,

                  

                  Can you please address Mehmet's comments.

                  

                  Regards, Benoit

                  


                    

                    -------- Original Message --------
                    

                      
                        

                          Subject: 
                          [OPS-DIR] OPS-DIR Review of
                            draft-ietf-radext-ipv6-access-13
                        

                        

                          Date: 
                          Tue, 20 Nov 2012 14:38:15 +0100
                        

                        

                          From: 
                          Ersue, Mehmet (NSN - DE/Munich) 
                              <mehmet.ersue at nsn.com>
                        

                        

                          To: 
                          <ops-dir
                              at ietf.org>,
                            
                              <draft-ietf-radext-ipv6-access at
                              tools.ietf.org>
                        

                      
                    

                    

                    

                    
I reviewed the draft "RADIUS attributes for IPv6 Access Networks" (
draft-ietf-radext-ipv6-access-13.txt) for its operational impact. 

Summary:
Intended status: Standards Track
Current status: Waiting for AD Go-Ahead 

The document specifies additional IPv6 RADIUS attributes useful in
residential broadband network deployments, which are:
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 document follows the standard method for Radius attribute
definition. As such the attributes and their configuration has been
sufficiently described.

I do not see any blocking issues.  The document seems to be ready for
publication as Proposed Standard.


Minor issues:

- Section 4.4. Delegated-IPv6-Prefix-Pool

I am not a AAA-NAS expert, however section 4.4. defines the
Delegated-IPv6-Prefix-Pool attribute containing the name of an assigned
pool that SHOULD be used to select an IPv6 delegated prefix for the user
on the NAS. But there is no mention of how the pool itself is defined. A
reference to the document where this has been specified would be useful
for the reader.


- There is one nit error (lines 453/454) which needs to be fixed:

** There are 2 instances of too long lines in the document, the longest
one
     being 3 characters in excess of 72.


453	   0+      0+     0      0         0+      TBA4
Delegated-IPv6-Prefix-Pool
454	   0+      0+     0      0         0+      TBA5
Stateful-IPv6-Address-Pool


- There is one nit warning:

== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
      document.

Cheers, 
Mehmet 


_______________________________________________
OPS-DIR mailing list
OPS-DIR at ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir




                    

                    

                  

                  

                		
            

          
        

        

        
        
Note Well:
            Messages sent to this mailing list are the opinions of the
            senders and do not imply endorsement by the IETF.

      

      

      

      

      
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext


    

    

  


--------------080105060101090106020304--

From internet-drafts@ietf.org  Fri Jan 11 03:48:51 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF9021F8815; Fri, 11 Jan 2013 03:48:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.543
X-Spam-Level: 
X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 gJeMXtD6OMsW; Fri, 11 Jan 2013 03:48:51 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0838C21F884A; Fri, 11 Jan 2013 03:48:51 -0800 (PST)
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.37
Message-ID: <20130111114851.14806.7188.idtracker@ietfa.amsl.com>
Date: Fri, 11 Jan 2013 03:48:51 -0800
Cc: radext@ietf.org
Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-15.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, 11 Jan 2013 11:48:51 -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)       : Wojciech Dec
                          Behcet Sarikaya
                          Glen Zorn
                          David Miles
                          Benoit Lourdelet
	Filename        : draft-ietf-radext-ipv6-access-15.txt
	Pages           : 12
	Date            : 2013-01-11

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-15

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-15


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From bclaise@cisco.com  Fri Jan 11 09:25:55 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A3321F899F for ; Fri, 11 Jan 2013 09:25:49 -0800 (PST)
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 F7viHKpkt9Ao for ; Fri, 11 Jan 2013 09:25:35 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 75D2821F87E3 for ; Fri, 11 Jan 2013 09:25:24 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0BHOxAd028085; Fri, 11 Jan 2013 18:24:59 +0100 (CET)
Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0BHOSEC023331; Fri, 11 Jan 2013 18:24:44 +0100 (CET)
Message-ID: <50F04ACC.8020301@cisco.com>
Date: Fri, 11 Jan 2013 18:24:28 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Alan DeKok 
References: <50C1CA9F.40100@cisco.com> <50C210F8.5060107@cisco.com> <50DB4F89.5090909@deployingradius.com> <50E6B41D.5020201@cisco.com> <50E6E32D.7000001@cisco.com>
In-Reply-To: <50E6E32D.7000001@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "radext@ietf.org" , draft-ietf-radext-radius-extensions@tools.ietf.org
Subject: Re: [radext] AD review: draft-ietf-radext-radius-extensions - restarting the IETF LC
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, 11 Jan 2013 17:26:04 -0000

Dear all,

After consultation with the IESG, and according to RFC 3967, I'll 
restart the IETF LC with the down ref clearly mentioned.

Regards, Benoit

> Alan,
>>>> 9.
>>>> This document updates: 2865 , 
>>>> 2866 , 3575 
>>>> , 5176 
>>>> , 6158 
>>>> 
>>>> My guess is that those should be normative references
>>>    Sure... it's an informational document, but OK.
>> Maybe I'll stand corrected, but I think this is the right thing to 
>> do. Please apply the changes.
> After some more investigation, and reading RFC 3967 ...
> This document updates
>     RFC 2865, standard track
>     RFC 2866, informational
>     RFC 3575, standard track
>     RFC 5176, informational
>     RFC 6158, BCP
>
> I'm wondering why RFC 2866 and RFC 5176 were informational in the 
> first place. Maybe someone with a long history in the WG could shed 
> some light?
>
> From RFC 3967, we need to have a clear idea on the downref before the 
> IETF Last Call
>
>    For Standards Track or BCP documents requiring normative reference to
>    documents of lower maturity, the normal IETF Last Call procedure will
>    be issued, with the need for the downward reference explicitly
>    documented in the Last Call itself.  Any community comments on the
>    appropriateness of downward references will be considered by the IESG
>    as part of its deliberations.
>
> Regards, Benoit
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>
>


From iesg-secretary@ietf.org  Fri Jan 11 11:34:05 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF0121F8738; Fri, 11 Jan 2013 11:34:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.439
X-Spam-Level: 
X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 tSfIQoe68Hx1; Fri, 11 Jan 2013 11:34:04 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C9321F86AA; Fri, 11 Jan 2013 11:34:04 -0800 (PST)
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.37
Message-ID: <20130111193404.22262.33628.idtracker@ietfa.amsl.com>
Date: Fri, 11 Jan 2013 11:34:04 -0800
Cc: radext@ietf.org
Subject: [radext] UPDATED Last Call: 	(Remote Authentication Dial In User Service (RADIUS) Protocol	Extensions) 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: Fri, 11 Jan 2013 19:34:05 -0000

The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document:
- 'Remote Authentication Dial In User Service (RADIUS) Protocol
   Extensions'
   as Proposed Standard

Note that this document is Standards Track and has normative references 
to two Informational documents, RFCs 2866 and 5176. 
See http://www.ietf.org/mail-archive/web/radext/current/msg07979.html
for some history on those two RFCs.

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 2013-01-25. 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


   The Remote Authentication Dial In User Service (RADIUS) protocol is
   nearing exhaustion of its current 8-bit Attribute Type space.  In
   addition, experience shows a growing need for complex grouping, along
   with attributes which can carry more than 253 octets of data.  This
   document defines changes to RADIUS which address all of the above
   problems.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/ballot/


No IPR declarations have been submitted directly on this I-D.



From bernard_aboba@hotmail.com  Tue Jan 15 11:13:57 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AD411E80A6 for ; Tue, 15 Jan 2013 11:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.482
X-Spam-Level: 
X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 v-hQiWeBQtIz for ; Tue, 15 Jan 2013 11:13:55 -0800 (PST)
Received: from blu0-omc3-s19.blu0.hotmail.com (blu0-omc3-s19.blu0.hotmail.com [65.55.116.94]) by ietfa.amsl.com (Postfix) with ESMTP id C6DE921F85D7 for ; Tue, 15 Jan 2013 11:13:54 -0800 (PST)
Received: from BLU002-W49 ([65.55.116.72]) by blu0-omc3-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 15 Jan 2013 11:13:16 -0800
X-EIP: [Wdzz1gPv7SahfYequmtnBFtYgE6j0vPj]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_0facf4c4-b039-4910-b550-79e41cbf358b_"
From: Bernard Aboba 
To: Benoit Claise 
Date: Tue, 15 Jan 2013 11:13:16 -0800
Importance: Normal
In-Reply-To: <50F53205.2020209@cisco.com>
References: <50F5316E.905@cisco.com>,<50F53205.2020209@cisco.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Jan 2013 19:13:16.0928 (UTC) FILETIME=[5F89C800:01CDF354]
Cc: "radext@ietf.org" , Ralph Droms 
Subject: Re: [radext] Ready to go? New Version Notification - draft-ietf-softwire-6rd-radius-attrib-10.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, 15 Jan 2013 19:13:57 -0000

--_0facf4c4-b039-4910-b550-79e41cbf358b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

While Section 3 now does describe how authentication/authorization function=
s in a way that is compliant with RFC 2865 and 5080=2C there is no normativ=
e language and the requirements (e.g. for User-Name and User-Password attri=
butes=2C Message-Authenticator attribute) are not included in Section 4.2. =
 Also=2C it would be helpful to be explicit about the value of the Service-=
Type attribute in Access-Requests (I am assuming that this is no longer "Ca=
ll-Check"=2C since the User-Password attribute is included in the Access-Re=
quest).=20

Date: Tue=2C 15 Jan 2013 11:40:05 +0100
From: bclaise@cisco.com
To: bernard_aboba@hotmail.com
CC: rdroms@cisco.com
Subject: Fwd: Ready to go? New Version Notification - draft-ietf-softwire-6=
rd-radius-attrib-10.txt

=0A=
  =0A=
=0A=
    =0A=
  =0A=
  =0A=
    Hi Bernard=2C
=0A=
   =20
=0A=
    I'm specifically interested in your feedback=2C because my DISCUSS=0A=
    contains your concern.
=0A=
    See=0A=
https://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ball=
ot/#benoit-claise
=0A=
   =20
=0A=
    Regards=2C Benoit
=0A=
   =20
=0A=
     =20
=0A=
      -------- Original Message --------=0A=
      =0A=
        =0A=
          =0A=
            Subject:=0A=
            =0A=
            Ready to go? New Version Notification -=0A=
              draft-ietf-softwire-6rd-radius-attrib-10.txt=0A=
          =0A=
          =0A=
            Date: =0A=
            Tue=2C 15 Jan 2013 11:37:34 +0100=0A=
          =0A=
          =0A=
            From: =0A=
            Benoit Claise =0A=
          =0A=
          =0A=
            To: =0A=
            aaa-doctors@ietf.org =0A=
          =0A=
          =0A=
            CC: =0A=
            softwire-chairs@tools.ietf.org=2C Ralph Droms=0A=
              =2C Sean Turner=0A=
              =2C me =0A=
          =0A=
        =0A=
      =0A=
     =20
=0A=
     =20
=0A=
      =0A=
      Dear AAA doctors=2C
=0A=
     =20
=0A=
      I have to admit that I lost track of the (multiple) AAA doctor=0A=
      discussion(s) regarding this draft.
=0A=
      Does this version 10 address your concerns?
=0A=
     =20
=0A=
      Regards=2C Benoit
=0A=
     =20
=0A=
       =20
=0A=
        -------- Original Message --------=0A=
        =0A=
          =0A=
            =0A=
              Subject:=0A=
=0A=
              =0A=
              New Version Notification -=0A=
                draft-ietf-softwire-6rd-radius-attrib-10.txt=0A=
            =0A=
            =0A=
              Date:=0A=
              =0A=
              Mon=2C 14 Jan 2013 21:38:38 -0800=0A=
            =0A=
            =0A=
              From:=0A=
              =0A=
              internet-drafts@ietf.org=0A=
            =0A=
            =0A=
              To: =0A=
              softwire-chairs@tools.ietf.org=2C=0A=
                draft-ietf-softwire-6rd-radius-attrib@tools.ietf.org=2C=0A=
                rdroms.ietf@gmail.com=2C=0A=
                bclaise@cisco.com=2C=0A=
                turners@ieca.com=0A=
            =0A=
          =0A=
        =0A=
       =20
=0A=
       =20
=0A=
        A new version (-10) has been submitted for draft-ietf-softwire-6rd-=
radius-attrib:=0A=
http://www.ietf.org/internet-drafts/draft-ietf-softwire-6rd-radius-attrib-1=
0.txt=0A=
=0A=
=0A=
The IETF datatracker page for this Internet-Draft is:=0A=
https://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/=0A=
=0A=
Diff from previous version:=0A=
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-6rd-radius-attrib-10=
=0A=
=0A=
IETF Secretariat.=0A=
=0A=
=0A=
=0A=
=0A=
       =20
=0A=
      =0A=
     =20
=0A=
     =20
=0A=
    =0A=
   =20
 		 	   		  =

--_0facf4c4-b039-4910-b550-79e41cbf358b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





While Section 3 now does describ=
e how authentication/authorization functions in a way that is compliant wit=
h RFC 2865 and 5080=2C there is no normative language and the requirements =
(e.g. for User-Name and User-Password attributes=2C Message-Authenticator a=
ttribute) are not included in Section 4.2. =3B Also=2C it would be help=
ful to be explicit about the value of the Service-Type attribute in Access-=
Requests (I am assuming that this is no longer "Call-Check"=2C since the Us=
er-Password attribute is included in the Access-Request). 

Date: Tue=2C 15 J=
an 2013 11:40:05 +0100
From: bclaise@cisco.com
To: bernard_aboba@hotm=
ail.com
CC: rdroms@cisco.com
Subject: Fwd: Ready to go? New Version N=
otification - draft-ietf-softwire-6rd-radius-attrib-10.txt

=0A=
  =0A=
=0A=
    =0A=
  =0A=
  =0A=
    Hi Bernard=2C
=0A=
    
=0A=
    I'm specifically interested in your feedback=2C because my DISCUSS=0A=
    contains your concern.
=0A=
    See=0A=
https://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-att=
rib/ballot/#benoit-claise
=0A=
    
=0A=
    Regards=2C Benoit
=0A=
    

=0A=
      
=0A=
      -------- Original Message --------=0A=
      =0A=
        =0A=
          =0A=
            =0A=
            =0A=
          =0A=
          =0A=
            =0A=
            =0A=
          =0A=
          =0A=
            =0A=
            =0A=
          =0A=
          =0A=
            =0A=
            =0A=
          =0A=
          =0A=
            =0A=
            =0A=
          =0A=
        =0A=
      
Subject:=0A=
            Ready to go? New Version Notification -=0A=
              draft-ietf-softwire-6rd-radius-attrib-10.txt
Date: Tue=2C 15 Jan 2013 11:37:34 +0100
From: Benoit Claise <=3Bbclaise@cisco.com>=3B
To: aaa-doctors@ietf.org <=3Baaa-doctors@ietf.org>=
=3B
CC: softwire-chairs@tools.ietf.org=2C Ralph Dr=
oms=0A=
              <=3Brdroms@cisco.com>=3B=2C Sean Turner=0A=
              <=3Bturners@ieca.com>=3B=2C me <=3Bbclaise@cisco.com>=3B=

=0A=
      
=0A=
      
=0A=
      =0A=
      Dear AAA doctors=2C
=0A=
      
=0A=
      I have to admit that I lost track of the (multiple) AAA doctor=0A=
      discussion(s) regarding this draft.
=0A=
      Does this version 10 address your concerns?
=0A=
      
=0A=
      Regards=2C Benoit
=0A=
      

=0A=
        
=0A=
        -------- Original Message --------=0A=
        =0A=
          =0A=
            =0A=
              =0A=
              =0A=
            =0A=
            =0A=
              =0A=
              =0A=
            =0A=
            =0A=
              =0A=
              =0A=
            =0A=
            =0A=
              =0A=
              =0A=
            =0A=
          =0A=
        
Subject:=0A=
=0A=
              New Version Notification -=0A=
                draft-ietf-softwire-6rd-radius-attrib-10.txt
Date:=0A=
              Mon=2C 14 Jan 2013 21:38:38 -0800
From:=0A=
              internet-drafts@ietf.org
To: softwire-chairs@tools.ietf.org=2C=0A=
                draft-ietf-softwire-6rd-=
radius-attrib@tools.ietf.org=2C=0A=
                rdroms.ietf@gmail.com=2C=0A=
                bclaise@cisco.com=2C=0A=
                turners@ieca.com
=0A=
        
=0A=
        
=0A=
        
A new version (-10) has been submitted for draft-ietf-softwire=
-6rd-radius-attrib:=0A=
http=
://www.ietf.org/internet-drafts/draft-ietf-softwire-6rd-radius-attrib-10.tx=
t=0A=
=0A=
=0A=
The IETF datatracker page for this Internet-Draft is:=0A=
https://datat=
racker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/=0A=
=0A=
Diff from previous version:=0A=
http://ww=
w.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-6rd-radius-attrib-10=0A=
=0A=
IETF Secretariat.=0A=
=0A=
=0A=
=0A=

=0A=
        
=0A=
      
=0A=
      
=0A=
      
=0A=
    
=0A=
    
 		 	   		  

=

--_0facf4c4-b039-4910-b550-79e41cbf358b_--

From bernard_aboba@hotmail.com  Wed Jan 16 14:12:41 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C73721F862A for ; Wed, 16 Jan 2013 14:12:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.35
X-Spam-Level: 
X-Spam-Status: No, score=-99.35 tagged_above=-999 required=5 tests=[AWL=-3.048, BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3, MIME_QP_LONG_LINE=1.396, 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 t7hxXbOkhhkF for ; Wed, 16 Jan 2013 14:12:40 -0800 (PST)
Received: from blu0-omc4-s26.blu0.hotmail.com (blu0-omc4-s26.blu0.hotmail.com [65.55.111.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2834B11E80A6 for ; Wed, 16 Jan 2013 14:12:25 -0800 (PST)
Received: from BLU402-EAS197 ([65.55.111.135]) by blu0-omc4-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jan 2013 14:12:24 -0800
X-EIP: [2JCi3Xpm8IPBkwASrpSlvYxPjQ4V5T4o]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="Apple-Mail-DDC85CBC-F417-4E2C-8590-12677BD3FC9D"
Content-Transfer-Encoding: 7bit
References: <66817D1D472FBD45AA4DE2CF935F91DAA2DAA057@CNEDCEX4.corp.local>
From: Bernard Aboba 
In-Reply-To: <66817D1D472FBD45AA4DE2CF935F91DAA2DAA057@CNEDCEX4.corp.local>
Date: Wed, 16 Jan 2013 14:12:24 -0800
To: "Warne, Cheryl A." , "radext@ietf.org" 
MIME-Version: 1.0 (1.0)
X-OriginalArrivalTime: 16 Jan 2013 22:12:24.0378 (UTC) FILETIME=[8FEE41A0:01CDF436]
Subject: Re: [radext] RFC 4282 - Correct usage when no home-realm
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, 16 Jan 2013 22:12:41 -0000

--Apple-Mail-DDC85CBC-F417-4E2C-8590-12677BD3FC9D
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



On Jan 16, 2013, at 8:30 AM, "Warne, Cheryl A."  wrote:

> Sir,
> =20
> I would like to verify the correct construction to use when the original N=
AI does not include a home-realm.
> =20
> Original NAI-1: johndoe@mymso.net
> Original NAI-2: jandoe
> Routing Realm: partnermso.net
> =20
> NAI-1 sent to partner: mymso.net!johndoe@partnermso.net
> NAI-2 sent to partner:  Should it be jandoe@partnermso.net or !jandoe@part=
nermso.net ?
> =20
> Thank you,
> =20
> Cherie Warne=20
> Bright House Networks | Network Engineering and Operations
> 
> 65 South Keller Road, Orlando, FL  32810
>=20
>=20
>=20
> =20
> =20
>=20
>=20
> CONFIDENTIALITY NOTICE: This e-mail may contain information that is privil=
eged, confidential or otherwise protected from disclosure. If you are not th=
e intended recipient of this e-mail, please notify the sender immediately by=
 return e-mail, purge it and do not disseminate or copy it.

--Apple-Mail-DDC85CBC-F417-4E2C-8590-12677BD3FC9D
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




On Jan 16, 2013, at 8:30 AM, "Warne, Cheryl A." <Cherie.Warne@mybrighthouse.com> wrote:









Sir,


 


I would like to verify the correct construction to use when the original NAI does not include a home-realm.


 


Original NAI-1: johndoe@mymso.net


Original NAI-2: jandoe


Routing Realm: partnermso.net


 


NAI-1 sent to partner: 
mymso.net!johndoe@partnermso.net


NAI-2 sent to partner:  Should it be 
jandoe@partnermso.net or !jandoe@partnermso.net ?


 


Thank you,


 


Cherie Warne


Bright House Networks | Network Engineering and Operations

<image001.jpg>

65 South Keller Road, Orlando, FL  32810








 


 









CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do
 not disseminate or copy it.






--Apple-Mail-DDC85CBC-F417-4E2C-8590-12677BD3FC9D--

From aland@deployingradius.com  Wed Jan 16 14:59:38 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F4511E80C5 for ; Wed, 16 Jan 2013 14:59:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.449
X-Spam-Level: 
X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_NAIL=2.3, 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 aHYxulZTmFkE for ; Wed, 16 Jan 2013 14:59:37 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8782E11E809A for ; Wed, 16 Jan 2013 14:59:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id DC3E72240BA0; Wed, 16 Jan 2013 23:59:34 +0100 (CET)
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 upJEwmOGNPbv; Wed, 16 Jan 2013 23:59:32 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 0B4E722409EA; Wed, 16 Jan 2013 23:59:31 +0100 (CET)
Message-ID: <50F730D2.9030702@deployingradius.com>
Date: Wed, 16 Jan 2013 17:59:30 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: "radext@ietf.org" 
References: <66817D1D472FBD45AA4DE2CF935F91DAA2DAA057@CNEDCEX4.corp.local> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "Warne, Cheryl A." 
Subject: Re: [radext] RFC 4282 - Correct usage when no home-realm
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, 16 Jan 2013 22:59:38 -0000

> On Jan 16, 2013, at 8:30 AM, "Warne, Cheryl A."
> >
> wrote:
>>
>> I would like to verify the correct construction to use when the
>> original NAI does not include a home-realm.
>>
>> Original NAI-1: johndoe@mymso.net
>>
>> Original NAI-2: jandoe
>>
>> Routing Realm: partnermso.net

  I'll note that RFC 4282 does not contain the concept of a "routing
realm".  It refers to routing by realm, but is clear that the realm in
question is the realm in the NAI.

  My interpretation is that the basis for the question is largely
outside of the scope of 4282.

>> NAI-1 sent to partner: mymso.net!johndoe@partnermso.net
>>
>> NAI-2 sent to partner:  Should it be jandoe@partnermso.net
>>  or !jandoe@partnermso.net ?

  RFC 4282 doesn't describe how NAIs are re-written or modified.

  So again the question is outside of the scope of 4282.

  The updated NAI document (draft-ietf-radext-nai-01.txt) contains new
text based on existing practice and RADEXT working group input.  It
suggests that routing is based on the NAI *as seen*.  It also says
modifications as seen above wrong:

...
   Some systems have historically used NAI modifications with multiple
   "prefix" and "suffix" decorations to perform explicit routing through
   multiple proxies inside of a AAA network.  This practice is NOT
   RECOMMENDED for the following reasons:
...


  I think this question is based on a whole set of unstated assumptions.
 For example, that a "routing realm" exists (whatever that is); that the
NAI is re-written (why?); that the "routing realm" is added to the NAI
in some form; etc.

 Alan DeKok.

From bclaise@cisco.com  Thu Jan 17 01:40:08 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37D721F86D2 for ; Thu, 17 Jan 2013 01:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.587
X-Spam-Level: 
X-Spam-Status: No, score=-10.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7tobSmNUx0fc for ; Thu, 17 Jan 2013 01:40:07 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5A71921F86C8 for ; Thu, 17 Jan 2013 01:40:02 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0H9NcL2027612; Thu, 17 Jan 2013 10:23:38 +0100 (CET)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0H9N2r0008144; Thu, 17 Jan 2013 10:23:13 +0100 (CET)
Message-ID: <50F7C2F6.9080009@cisco.com>
Date: Thu, 17 Jan 2013 10:23:02 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: draft-ietf-radext-radius-extensions@tools.ietf.org
References: <20130117180958.bbe07f26ac659d782bffbf02@jprs.co.jp>
In-Reply-To: <20130117180958.bbe07f26ac659d782bffbf02@jprs.co.jp>
X-Forwarded-Message-Id: <20130117180958.bbe07f26ac659d782bffbf02@jprs.co.jp>
Content-Type: multipart/alternative; boundary="------------010706020409050404070101"
Cc: "radext@ietf.org" 
Subject: [radext] Fwd: APPSDIR review of draft-ietf-radext-radius-extensions-08
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, 17 Jan 2013 09:40:08 -0000

This is a multi-part message in MIME format.
--------------010706020409050404070101
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

draft-ietf-radext-radius-extensions authors,

In the next version of the document, please address the editorial 
comments below.

Regards, Benoit


-------- Original Message --------
Subject: 	APPSDIR review of draft-ietf-radext-radius-extensions-08
Resent-Date: 	Thu, 17 Jan 2013 09:10:21 GMT
Resent-From: 	draft-alias-bounces@tools.ietf.org
Resent-To: 	aland@networkradius.com, avi@bridgewatersystems.com, 
bclaise@cisco.com, jouni.nospam@gmail.com, mauricio.sanchez@hp.com
Date: 	Thu, 17 Jan 2013 18:09:58 +0900
From: 	Yoshiro YONEYA 
To: 	apps-discuss@ietf.org, 
draft-ietf-radext-radius-extensions.all@tools.ietf.org
CC: 	iesg@ietf.org



I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive.  Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-radext-radius-extensions-08
Title: Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
Reviewer: Yoshiro Yoneya
Review Date: 2013-01-17
IETF Last Call Date: 2013-01-25
IESG Telechat Date: unknown

Summary:

This draft is ready for publication as a Proposed Standard RFC.

Major Issues:
   none

Minor Issues:
   none

Nits:

- Section 1.1.1. [Page 6]
   One gaol which was not ...
   -> One goal which was not ...

- Section 2. [Page 9]
   ...
   so that the definition of the Length field remains unchanged.  The
   new attribute formats are designed to be compatible with the
   ...
   so that the definition of the Length field remains unchanged.
   -> [The same sentences are repeated twice.  Remove duplicated one.]

- Section 6.5. [Page 40]
   Specifications which allocate many attributes MUST NOT request that
   allocation be made from from the standard space.
   -> Specifications which allocate many attributes MUST NOT request that
      allocation be made from the standard space.
   
- Section 6.6. [Page 41]
   Where a group of TLVs is strictly defined, and not expected to
   change, and and totals less than 247 octets of data,
   -> Where a group of TLVs is strictly defined, and not expected to
      change, and totals less than 247 octets of data,

Regards,

-- 
Yoshiro YONEYA 





--------------010706020409050404070101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    draft-ietf-radext-radius-extensions authors,

    

    In the next version of the document, please address the editorial
    comments below.

    

    Regards, Benoit

    


      

      -------- Original Message --------
      

        
          

            Subject:
            
            APPSDIR review of draft-ietf-radext-radius-extensions-08
          

          

            Resent-Date:
            
            Thu, 17 Jan 2013 09:10:21 GMT
          

          

            Resent-From:
            
            draft-alias-bounces@tools.ietf.org
          

          

            Resent-To:
            
            aland@networkradius.com, avi@bridgewatersystems.com,
              bclaise@cisco.com, jouni.nospam@gmail.com,
              mauricio.sanchez@hp.com
          

          

            Date: 
            Thu, 17 Jan 2013 18:09:58 +0900
          

          

            From: 
            Yoshiro YONEYA <yoshiro.yoneya@jprs.co.jp>
          

          

            To: 
            apps-discuss@ietf.org,
              draft-ietf-radext-radius-extensions.all@tools.ietf.org
          

          

            CC: 
            iesg@ietf.org
          

        
      

      

      

      
I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive.  Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-radext-radius-extensions-08
Title: Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
Reviewer: Yoshiro Yoneya
Review Date: 2013-01-17
IETF Last Call Date: 2013-01-25
IESG Telechat Date: unknown

Summary:

This draft is ready for publication as a Proposed Standard RFC.

Major Issues:
  none

Minor Issues:
  none

Nits:

- Section 1.1.1. [Page 6]
  One gaol which was not ...
  -> One goal which was not ...

- Section 2. [Page 9]
  ...
  so that the definition of the Length field remains unchanged.  The
  new attribute formats are designed to be compatible with the
  ...
  so that the definition of the Length field remains unchanged.
  -> [The same sentences are repeated twice.  Remove duplicated one.]

- Section 6.5. [Page 40]
  Specifications which allocate many attributes MUST NOT request that
  allocation be made from from the standard space.
  -> Specifications which allocate many attributes MUST NOT request that
     allocation be made from the standard space.
  
- Section 6.6. [Page 41]
  Where a group of TLVs is strictly defined, and not expected to
  change, and and totals less than 247 octets of data,
  -> Where a group of TLVs is strictly defined, and not expected to
     change, and totals less than 247 octets of data,

Regards,

-- 
Yoshiro YONEYA <yoshiro.yoneya@jprs.co.jp>




      

    

    

  


--------------010706020409050404070101--

From aland@deployingradius.com  Thu Jan 17 05:24:46 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5771C21F886D; Thu, 17 Jan 2013 05:24:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.494
X-Spam-Level: 
X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 wWjcb2mr7oGL; Thu, 17 Jan 2013 05:24:45 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74DE821F8868; Thu, 17 Jan 2013 05:24:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 5D3742240F0C; Thu, 17 Jan 2013 14:24:44 +0100 (CET)
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 ZyyyeFTXHSqR; Thu, 17 Jan 2013 14:24:43 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 178752240821; Thu, 17 Jan 2013 14:24:42 +0100 (CET)
Message-ID: <50F7FB9A.6020006@deployingradius.com>
Date: Thu, 17 Jan 2013 08:24:42 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Yoshiro YONEYA 
References: <20130117180958.bbe07f26ac659d782bffbf02@jprs.co.jp>
In-Reply-To: <20130117180958.bbe07f26ac659d782bffbf02@jprs.co.jp>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: "Benoit Claise \(bclaise\)" , "radext@ietf.org" , iesg@ietf.org, apps-discuss@ietf.org, draft-ietf-radext-radius-extensions.all@tools.ietf.org
Subject: Re: [radext] APPSDIR review of draft-ietf-radext-radius-extensions-08
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, 17 Jan 2013 13:24:46 -0000

  Thanks.  I've made the changes, and they will appear in the next rev
of the document.

Yoshiro YONEYA wrote:
> I have been selected as the Applications Area Directorate reviewer for 
> this draft (for background on appsdir, please see 
> ​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.  Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-radext-radius-extensions-08
> Title: Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
> Reviewer: Yoshiro Yoneya
> Review Date: 2013-01-17
> IETF Last Call Date: 2013-01-25
> IESG Telechat Date: unknown
> 
> Summary:
> 
> This draft is ready for publication as a Proposed Standard RFC.
> 
> Major Issues:
>   none
> 
> Minor Issues:
>   none
> 
> Nits:
> 
> - Section 1.1.1. [Page 6]
>   One gaol which was not ...
>   -> One goal which was not ...
> 
> - Section 2. [Page 9]
>   ...
>   so that the definition of the Length field remains unchanged.  The
>   new attribute formats are designed to be compatible with the
>   ...
>   so that the definition of the Length field remains unchanged.
>   -> [The same sentences are repeated twice.  Remove duplicated one.]
> 
> - Section 6.5. [Page 40]
>   Specifications which allocate many attributes MUST NOT request that
>   allocation be made from from the standard space.
>   -> Specifications which allocate many attributes MUST NOT request that
>      allocation be made from the standard space.
>   
> - Section 6.6. [Page 41]
>   Where a group of TLVs is strictly defined, and not expected to
>   change, and and totals less than 247 octets of data,
>   -> Where a group of TLVs is strictly defined, and not expected to
>      change, and totals less than 247 octets of data,
> 
> Regards,
> 


From stefan.winter@restena.lu  Fri Jan 18 04:01:18 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE9221F88B2 for ; Fri, 18 Jan 2013 04:01:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6]
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 qRs4DcBNO+4E for ; Fri, 18 Jan 2013 04:01:17 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFA321F84D8 for ; Fri, 18 Jan 2013 04:01:17 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id D756B10589 for ; Fri, 18 Jan 2013 13:01:15 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:a815:cd48:7d7e:9e97] (unknown [IPv6:2001:a18:1:8:a815:cd48:7d7e:9e97]) by smtprelay.restena.lu (Postfix) with ESMTPS id CC5911057F for ; Fri, 18 Jan 2013 13:01:15 +0100 (CET)
Message-ID: <50F93987.4090302@restena.lu>
Date: Fri, 18 Jan 2013 13:01:11 +0100
From: Stefan Winter 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2
MIME-Version: 1.0
To: radext@ietf.org
References: <066.7bde70b0716a3259e78af5bfff386bfa@trac.tools.ietf.org>
In-Reply-To: <066.7bde70b0716a3259e78af5bfff386bfa@trac.tools.ietf.org>
X-Enigmail-Version: 1.5
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2CLVNQQQBPVKPQVVOVBSM"
X-Virus-Scanned: ClamAV
Subject: Re: [radext] #147: Internationalization and draft-ietf-radext-dynamic-discovery
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, 18 Jan 2013 12:01:18 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2CLVNQQQBPVKPQVVOVBSM
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

>  Currently the internationalization advice provided in Section 2.3.1
>  appears to differ from that provided in RFC 4282bis, creating potentia=
lly
>  unpredictable interactions.
>=20
>     Dynamic server discovery as defined in this document is only
>     applicable for AAA transactions where a RADIUS server receives a
>     request with a realm for which no home RADIUS server is known.
>=20
>  [BA] Does this paragraph really apply to RADIUS servers and not proxie=
s?
>  Typically a server will only check the realm and see if it represents =
a
>  realm it is serving; if not an error is flagged.  Asking RADIUS server=
s
>  (not proxies) to route for realms for which they are not authoritative=

>  seems dangerous.

That's right; the text should rather state "RADIUS proxies".

Is it worth forging the text a bit more fine-grained to take into
account that there are RADIUS entities which are both RADIUS server for
a certain realm, and RADIUS proxy for others?

In eduroam, this is quite common: a RADIUS server is authoritative for
realm foo.xy, but may receive requests from any other realm; in which
case it is *not* supposed to flag an error as you state above, but
instead trigger discovery (or in absence of a corresponding DNS entry
send to a known "DEFAULT" proxy).

The wording would then be a bit more difficult/clumsy. Like:

     Dynamic server discovery as defined in this document is only
     applicable for AAA transactions where a RADIUS entity which acts
     as a proxy for one or more realms receives a request with a realm
     for which it is not authoritative.

>  Also, the meaning of "no home RADIUS server is known" is not clear.

This was supposed to mean: there is no entry in the realm routing table
for the specific realm encountered in the User-Name. Does the "is not
authoritative" wording fix this for you?

>  According to RFC 4282bis, only bit-by-bit comparisons are supported in=
 the
>  AAA infrastructure.  As a result, were a client to not provide a
>  normalized realm, the resulting failure of the  comparison would trigg=
er
>  use of dynamic server discovery.  Is this what is intended??

Yes; an authoritative server should list its own realm in its
configuration in all the variants it expects.

If an unexpected variant comes along, dynamic discovery is triggered. I
guess it is worth expanding the "loop prevention" advice from section
2.3.1 to cover this as well: if dynamic discovery is triggered because
of an unknown variant of the same realm, and dynamic discovery points
towards the proxy/server itself, the proxy should note that and not
enter dynamic discovery *again* to prevent a loop.

Thinking of it, it would algorithmically probably be best to add a new
final step of the algorithm: instead of terminating after step 7 or 14,
test the output set O whether it contains an IP/port combination on
which the proxy itself is listening; if yes, terminate with an error and
set O =3D { }.

>  Section 2.3.1
>=20
>     Note well: The attribute User-Name is defined to contain UTF-8 text=
=2E
>     In practice, the content may or may not be UTF-8.  Even if UTF-8, i=
t
>     may or may not map to a domain name in the realm part. Implementors=

>     MUST take possible conversion error paths into consideration when
>     parsing incoming User-Name attributes.
>=20
>  [BA] This would appear to contradict RFC 4282bis requirements for real=
m
>  normalization and realm correspondence to a legal FQDN.

As noted in another thread: 4282bis can state whatever it likes, but the
content of User-Name is constructed by end-users by typing something
into their keyboard (or similar). There is no guarantee that the
incoming value is in any way valid.

The text in 2.3.1 just makes implementers aware of that fact.

> Although Section
>  2.2 does mention conversion to punycode, the exact steps to be perform=
ed
>  are not described:
>=20
>     It is expected that in most cases, the label used for the records i=
s
>     the DNS representation (punycode) of the literal realm name for whi=
ch
>     the server is the RADIUS server.

Hm. I don't know how to word this in a better way than hand-waving. Can
I just reference a section of an RFC? If yes, which?

What I intended to say was: assume a RADIUS server is authoritative for
the realm "tu-m=FCnchen.example". The DNS label in section 2.2 would then=

be _radiustls._tcp.xn--tu-mnchen-t9a.example.

So, it's about getting from "tu-m=FCnchen.example" to
"xn--tu-mnchen-t9a.example". I'm sure the Internationalised DNS RFCs
have a deterministic way of getting there?

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


------enig2CLVNQQQBPVKPQVVOVBSM
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 Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlD5OYsACgkQ+jm90f8eFWb7JwCfQOv54NpjefUJmXY4NkAbTBx5
WEMAn2466cEbjkybLBmF9LYd8okUMTjN
=VcT1
-----END PGP SIGNATURE-----

------enig2CLVNQQQBPVKPQVVOVBSM--

From stefan.winter@restena.lu  Fri Jan 18 04:22:53 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE2821F85E0 for ; Fri, 18 Jan 2013 04:22:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,  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 IT8w99s9b3FK for ; Fri, 18 Jan 2013 04:22:52 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A51CC21F84CE for ; Fri, 18 Jan 2013 04:22:52 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 119A610589 for ; Fri, 18 Jan 2013 13:22:52 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:a815:cd48:7d7e:9e97] (unknown [IPv6:2001:a18:1:8:a815:cd48:7d7e:9e97]) by smtprelay.restena.lu (Postfix) with ESMTPS id DA82B10580 for ; Fri, 18 Jan 2013 13:22:51 +0100 (CET)
Message-ID: <50F93E97.5070202@restena.lu>
Date: Fri, 18 Jan 2013 13:22:47 +0100
From: Stefan Winter 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2
MIME-Version: 1.0
To: radext@ietf.org
References: <066.7bde70b0716a3259e78af5bfff386bfa@trac.tools.ietf.org> <50F93987.4090302@restena.lu>
In-Reply-To: <50F93987.4090302@restena.lu>
X-Enigmail-Version: 1.5
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2HSTXSCMGUCCUERXNHUXP"
X-Virus-Scanned: ClamAV
Subject: Re: [radext] #147: Internationalization and draft-ietf-radext-dynamic-discovery
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, 18 Jan 2013 12:22:53 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2HSTXSCMGUCCUERXNHUXP
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi again,

> Hm. I don't know how to word this in a better way than hand-waving. Can=

> I just reference a section of an RFC? If yes, which?
>=20
> What I intended to say was: assume a RADIUS server is authoritative for=

> the realm "tu-m=FCnchen.example". The DNS label in section 2.2 would th=
en
> be _radiustls._tcp.xn--tu-mnchen-t9a.example.
>=20
> So, it's about getting from "tu-m=FCnchen.example" to
> "xn--tu-mnchen-t9a.example". I'm sure the Internationalised DNS RFCs
> have a deterministic way of getting there?

I'm looking at RFC5891 now. Would referencing Section 5 of that RFC be
enough? The text would then be:

    It is expected that in most cases, the label used for the records is
    the DNS A-label representation of the literal realm name for
    which the server is the authoritative RADIUS server (i.e. the realm
    name after conversion according to section 5 of [RFC5891]).

Would that do?

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


------enig2HSTXSCMGUCCUERXNHUXP
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 Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlD5PpsACgkQ+jm90f8eFWZ2uwCfZlm2dYQtzzLr06MFd652ef3j
/rgAnArEia4bAv+5O366evTiqgdr1z+H
=XyCv
-----END PGP SIGNATURE-----

------enig2HSTXSCMGUCCUERXNHUXP--

From hartmans@painless-security.com  Fri Jan 18 12:14:24 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D83021F8770 for ; Fri, 18 Jan 2013 12:14:24 -0800 (PST)
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 N3F1v-VdLD-O for ; Fri, 18 Jan 2013 12:14:23 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 42E6821F8767 for ; Fri, 18 Jan 2013 12:14:23 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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 8E83220289; Fri, 18 Jan 2013 15:10:54 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 16F3943F7; Fri, 18 Jan 2013 15:14:20 -0500 (EST)
From: Sam Hartman 
To: Stefan Winter 
References: <066.7bde70b0716a3259e78af5bfff386bfa@trac.tools.ietf.org> <50F93987.4090302@restena.lu> <50F93E97.5070202@restena.lu>
Date: Fri, 18 Jan 2013 15:14:20 -0500
In-Reply-To: <50F93E97.5070202@restena.lu> (Stefan Winter's message of "Fri, 18 Jan 2013 13:22:47 +0100")
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] #147: Internationalization and draft-ietf-radext-dynamic-discovery
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, 18 Jan 2013 20:14:24 -0000

>>>>> "Stefan" == Stefan Winter  writes:

    Stefan> Hi again,
    Stefan>     It is expected that in most cases, the label used for
    Stefan> the records is the DNS A-label representation of the literal
    Stefan> realm name for which the server is the authoritative RADIUS
    Stefan> server (i.e. the realm name after conversion according to
    Stefan> section 5 of [RFC5891]).

I think that's good.

From aland@deployingradius.com  Fri Jan 18 12:22:08 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA0121F8765 for ; Fri, 18 Jan 2013 12:22:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.503
X-Spam-Level: 
X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 G28l6YXkvL3v for ; Fri, 18 Jan 2013 12:22:07 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 088BE21F8756 for ; Fri, 18 Jan 2013 12:22:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 683C52240F0C; Fri, 18 Jan 2013 21:22:05 +0100 (CET)
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 NLewQi0vw3Io; Fri, 18 Jan 2013 21:22:02 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 173A82240D85; Fri, 18 Jan 2013 21:22:01 +0100 (CET)
Message-ID: <50F9AEE8.9070105@deployingradius.com>
Date: Fri, 18 Jan 2013 15:22:00 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Jim Schaad 
References: <023601cdf5b2$fa462fe0$eed28fa0$@augustcellars.com>
In-Reply-To: <023601cdf5b2$fa462fe0$eed28fa0$@augustcellars.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: radext@ietf.org, draft-ietf-radext-nai@tools.ietf.org
Subject: Re: [radext] Comments on draft-ietf-radext-nai-01
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, 18 Jan 2013 20:22:08 -0000

Jim Schaad wrote:
> Some additional comments to be considered
> 
> 1.  I like the addition of the term "local" in section 1.1.  I wonder if the
> following text should be added
> 
> "AAA entities not under the control of the client that "know" the locale may
> have a different concept of that information than the client's locale."

  Sounds good to me.  That sounds a little convoluted to me.  I'll
rephrase it as:

The client which "knows" the locale may have a different concept of
this text than other AAA entities, which do not know the locale.

> 2.  In a follow up to my last set of comments:  Does the working group feel
> there is any need to remove the restriction that there be at least one dot
> in a utf8-realm.  Given the possibility of new top level domains being
> issued such as "Walmart", what are the odds that those people are going to
> want to be able to use a NAI of the form joe@walmart for an NAI?

  My $0.02 is that allowing top-level domains as the NAI is problematic,
and not in line with historical practice.

  But... I can see people asking for it.

> 3.  In section 2.8, if one is expected to use the utf8-realm with a
> byte-for-byte comparison, then one needs to specify a canonicalization of
> those sub-sections of the utf8-realm that are equivalent to A-labels.

  I am very wary of suggesting that.  The goal for the NAI is to be
agnostic as to A-label or U-label.  Those terms refer to DNS, and the
utf8-realm is defined independently of DNS.

>  That
> is "example.com" and "EXAMPLE.COM" should be routed to the same location
> because they are using A-Labels in the utf8-realm while "exαmple.com" and
> "EXΑMPLE.COM" (A and uppercase α have the same glyph) are not routed to the
> same location because they are using U-Labels in the utf8-realm.

  That is a good point, and one which should be clarified in the document.

  But my take is that "example.com" and "EXAMPLE.COM" should be treated
differently.  i.e. intermediate nodes don't know locale, and cannot do
canonicalization.  We might as well go with that everywhere, rather than
trying to make exceptions for ASCII.

> 4.  In section 2.10, my understanding of the DNS terminology is different
> than what is presented here.  In order for it to be a U-Label, the label
> must have a non-ASCII character.  If the section consists only of ASCII
> characters then it is an A-Label.  This means that the text in the first
> paragraph is incorrect when saying the utf8-realm is not composed of
> A-labels.

  Well.. the utf8-realm can be entirely U-labels, and does not need to
be A-labels.

>  I believe that the correct sentence would be "As defined above,
> the "utf8-realm" portion as transported within the RADIUS User-Name
> attribute can be composed of both U-labels and A-labels."

  It might be simpler just to say that the NAI is 8-bit clean, and
therefore avoids the U-label and A-label distinction.

  How about this:


The "utf8-realm" portion of the NAI is intended to be compatible with
Internationalized Domain Names [RFC5890].  As defined above, the
"utf8-realm" portion as transported within the RADIUS User-Name
attribute can transport any valid UTF8 character.  There is therefore
no reason for a NAS to apply the ToAscii function to the "utf8-realm"
portion of an NAI, prior to placing the NAI into a RADIUS User-Name
attribute.  Unlike DNS, the NAI does not make a distinction between
A-labels and U-labels.

  Alan DeKok.

From bernard_aboba@hotmail.com  Fri Jan 18 12:45:04 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1124721F86D3 for ; Fri, 18 Jan 2013 12:45:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.182
X-Spam-Level: 
X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 75jrT5igvrZv for ; Fri, 18 Jan 2013 12:45:03 -0800 (PST)
Received: from blu0-omc1-s12.blu0.hotmail.com (blu0-omc1-s12.blu0.hotmail.com [65.55.116.23]) by ietfa.amsl.com (Postfix) with ESMTP id 63D8121F86CA for ; Fri, 18 Jan 2013 12:45:03 -0800 (PST)
Received: from BLU002-W131 ([65.55.116.9]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 18 Jan 2013 12:45:02 -0800
X-EIP: [M1XLxR6ol+NMEdg+7OyHsz2nuqCSuShc]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_998fd009-23c5-49f0-ba3b-0e39119320ab_"
From: Bernard Aboba 
To: Sam Hartman , Stefan Winter 
Date: Fri, 18 Jan 2013 12:45:01 -0800
Importance: Normal
In-Reply-To: 
References: <066.7bde70b0716a3259e78af5bfff386bfa@trac.tools.ietf.org>, <50F93987.4090302@restena.lu> <50F93E97.5070202@restena.lu>,
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Jan 2013 20:45:02.0383 (UTC) FILETIME=[B048CBF0:01CDF5BC]
Cc: "radext@ietf.org" 
Subject: Re: [radext] #147: Internationalization and draft-ietf-radext-dynamic-discovery
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, 18 Jan 2013 20:45:04 -0000

--_998fd009-23c5-49f0-ba3b-0e39119320ab_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

It makes sense to say that Dynamic Discovery will utilize an A-label repres=
entation in retrieving RRs from DNS.=20

But we do need to be clear about what is expected in the User-Name attribut=
e (e.g. U-labels=2C not A-labels).=20

> From: hartmans@painless-security.com
> To: stefan.winter@restena.lu
> Date: Fri=2C 18 Jan 2013 15:14:20 -0500
> CC: radext@ietf.org
> Subject: Re: [radext] #147: Internationalization and	draft-ietf-radext-dy=
namic-discovery
>=20
> >>>>> "Stefan" =3D=3D Stefan Winter  writes:
>=20
>     Stefan> Hi again=2C
>     Stefan>     It is expected that in most cases=2C the label used for
>     Stefan> the records is the DNS A-label representation of the literal
>     Stefan> realm name for which the server is the authoritative RADIUS
>     Stefan> server (i.e. the realm name after conversion according to
>     Stefan> section 5 of [RFC5891]).
>=20
> I think that's good.
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
 		 	   		  =

--_998fd009-23c5-49f0-ba3b-0e39119320ab_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





It makes sense to say that Dynam=
ic Discovery will utilize an A-label representation in retrieving RRs from =
DNS. 

But we do need to be clear about what is expected in the User-=
Name attribute (e.g. U-labels=2C not A-labels). 

>=3B From: hartmans@painless-security.com
>=
=3B To: stefan.winter@restena.lu
>=3B Date: Fri=2C 18 Jan 2013 15:14:2=
0 -0500
>=3B CC: radext@ietf.org
>=3B Subject: Re: [radext] #147:=
 Internationalization and	draft-ietf-radext-dynamic-discovery
>=3B >=3B >=3B>=3B>=3B>=3B>=3B "Stefan" =3D=3D Stefan Winter <=3B=
stefan.winter@restena.lu>=3B writes:
>=3B 
>=3B     Stefan>=
=3B Hi again=2C
>=3B     Stefan>=3B     It is expected that in most =
cases=2C the label used for
>=3B     Stefan>=3B the records is the D=
NS A-label representation of the literal
>=3B     Stefan>=3B realm n=
ame for which the server is the authoritative RADIUS
>=3B     Stefan&g=
t=3B server (i.e. the realm name after conversion according to
>=3B   =
  Stefan>=3B section 5 of [RFC5891]).
>=3B 
>=3B I think that's=
 good.
>=3B _______________________________________________
>=3B =
radext mailing list
>=3B radext@ietf.org
>=3B https://www.ietf.or=
g/mailman/listinfo/radext
 		 	   		  

=

--_998fd009-23c5-49f0-ba3b-0e39119320ab_--

From bernard_aboba@hotmail.com  Fri Jan 18 13:09:50 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0C521F8763 for ; Fri, 18 Jan 2013 13:09:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.201
X-Spam-Level: 
X-Spam-Status: No, score=-102.201 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 nk2zmLAjnVdT for ; Fri, 18 Jan 2013 13:09:49 -0800 (PST)
Received: from blu0-omc2-s32.blu0.hotmail.com (blu0-omc2-s32.blu0.hotmail.com [65.55.111.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1787021F8758 for ; Fri, 18 Jan 2013 13:09:49 -0800 (PST)
Received: from BLU002-W68 ([65.55.111.71]) by blu0-omc2-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 18 Jan 2013 13:09:48 -0800
X-EIP: [sZmX1OuQ84a7vzDc5uMwoR9WYX0HJ2HW]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_70365518-4e16-41d4-9993-e84bac4290bc_"
From: Bernard Aboba 
To: Alan DeKok , Jim Schaad 
Date: Fri, 18 Jan 2013 13:09:48 -0800
Importance: Normal
In-Reply-To: <50F9AEE8.9070105@deployingradius.com>
References: <023601cdf5b2$fa462fe0$eed28fa0$@augustcellars.com>, <50F9AEE8.9070105@deployingradius.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Jan 2013 21:09:48.0336 (UTC) FILETIME=[25FB3B00:01CDF5C0]
Cc: "radext@ietf.org" , "draft-ietf-radext-nai@tools.ietf.org" 
Subject: Re: [radext] Comments on draft-ietf-radext-nai-01
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, 18 Jan 2013 21:09:50 -0000

--_70365518-4e16-41d4-9993-e84bac4290bc_
Content-Type: text/plain; charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable


> > 2.  In a follow up to my last set of comments:  Does the working group =
feel
> > there is any need to remove the restriction that there be at least one =
dot
> > in a utf8-realm.  Given the possibility of new top level domains being
> > issued such as "Walmart"=2C what are the odds that those people are goi=
ng to
> > want to be able to use a NAI of the form joe@walmart for an NAI?
>   My $0.02 is that allowing top-level domains as the NAI is problematic=
=2C
> and not in line with historical practice.

[BA] I agree.  RFC 1536 is very clear that a single label has a locally def=
ined meaning.=20

That is=2C "walmart" in joe@walmart may be resolved via a search algorithm=
=20
(e.g. looking up walmart.example.com) or via a different name resolution
protocol. =20

Therefore including this would be dangerous.
=20
> > 3.  In section 2.8=2C if one is expected to use the utf8-realm with a
> > byte-for-byte comparison=2C then one needs to specify a canonicalizatio=
n of
> > those sub-sections of the utf8-realm that are equivalent to A-labels.
>=20
>   I am very wary of suggesting that.  The goal for the NAI is to be
> agnostic as to A-label or U-label.  Those terms refer to DNS=2C and the
> utf8-realm is defined independently of DNS.

[BA] Currently the document suffers from a lack of clarity that I believe w=
as part of the reason for the RFC 4282 debacle.=20

The "NAI" can have different representations depending on context.  RFC 428=
2 seemed to suffer from the delusion that there is a single unique encoding=
 of the NAI that is valid in every protocol or circumstance.   This documen=
t needs to dispense with that misguided notion early on=2C and make it very=
 clear what the ABNF applies to=2C exactly.

For example=2C an NAI realm contained in the RADIUS User-Name Attribute wil=
l have one representation (canonicalized U-labels on the wire) and an NAI r=
ealm as used to look up DNS RRs in RADIUS Dynamic Discovery will have anoth=
er representation (e.g. A-labels).  It also will matter if a protocol is 8-=
bit clean (like EAP and RADIUS) or requires escaping (SIP or HTTP).=20

> >  That
> > is "example.com" and "EXAMPLE.COM" should be routed to the same locatio=
n
> > because they are using A-Labels in the utf8-realm while "ex=E1mple.com"=
 and
> > "EX=C1MPLE.COM" (A and uppercase =E1 have the same glyph) are not route=
d to the
> > same location because they are using U-Labels in the utf8-realm.
>=20
>   That is a good point=2C and one which should be clarified in the docume=
nt.
>=20
>   But my take is that "example.com" and "EXAMPLE.COM" should be treated
> differently.  i.e. intermediate nodes don't know locale=2C and cannot do
> canonicalization.  We might as well go with that everywhere=2C rather tha=
n
> trying to make exceptions for ASCII.

[BA] The RADIUS Dynamic Discovery document seems to assert that in practice=
 intermediate nodes MAY need to do some canonicalization.  I would like to =
understand the experience that lies behind that assertion a bit better.  Fo=
r example=2C it is one thing to be referring to authentication mechanisms t=
hat are either only used locally or within EAP tunnel methods (e.g. MS-CHAP=
)=2C it is another to be referring to widely deployed implementations that =
won't comply with the recommendations in this document.  For example=2C as =
far as I know=2C no existing EAP implementation applies NFC to the NAI prio=
r to enclosing it in the EAP-Response/Identity.  As a result=2C it is not r=
ealistic to expect the User-Name to be canonicalized upon entering the AAA =
system=2C unless we are going to require the NAS to do the canonicalization=
 (and have some expectation it will actually happen).=20

>   It might be simpler just to say that the NAI is 8-bit clean=2C and
> therefore avoids the U-label and A-label distinction.

[BA] Stating that the "NAI is 8-bit clean" is very confusing=2C because the=
 NAI realm may be encoded with U-labels or A-labels depending on circumstan=
ce.  However=2C one can talk about "the representation of the NAI within an=
 8-bit clean protocol".    Let's make sure we do not repeat the mistakes of=
 RFC 4282. =20


> The "utf8-realm" portion of the NAI is intended to be compatible with
> Internationalized Domain Names [RFC5890].  As defined above=2C the
> "utf8-realm" portion as transported within the RADIUS User-Name
> attribute can transport any valid UTF8 character.  There is therefore
> no reason for a NAS to apply the ToAscii function to the "utf8-realm"
> portion of an NAI=2C prior to placing the NAI into a RADIUS User-Name
> attribute.  Unlike DNS=2C the NAI does not make a distinction between
> A-labels and U-labels.

I think the above is still suffering from "RFC4282 disease":  confusion bet=
ween the NAI and its representation within given protocols.  How about this=
?

> The "utf8-realm" portion of the NAI is intended to be compatible with
> Internationalized Domain Names [RFC5890].  As defined above=2C the
> "utf8-realm" portion as transported within an 8-bit clean protocol
> such as RADIUS and EAP can contain any valid UTF8 character. =20
>There is therefore no reason for a NAS to apply the ToAscii function to th=
e "utf8-realm"
> portion of an NAI=2C prior to placing the NAI into a RADIUS User-Name
> attribute. =20


 		 	   		  =

--_70365518-4e16-41d4-9993-e84bac4290bc_
Content-Type: text/html; charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable






>=3B >=3B 2.  In a =
follow up to my last set of comments:  Does the working group feel
>=
=3B >=3B there is any need to remove the restriction that there be at lea=
st one dot
>=3B >=3B in a utf8-realm.  Given the possibility of new =
top level domains being
>=3B >=3B issued such as "Walmart"=2C what a=
re the odds that those people are going to
>=3B >=3B want to be able=
 to use a NAI of the form joe@walmart for an NAI?
>=3B   My $0.02 is t=
hat allowing top-level domains as the NAI is problematic=2C
>=3B and n=
ot in line with historical practice.

[BA] I agree. =3B RFC 1536 =
is very clear that a single label has a locally defined meaning. 

Th=
at is=2C "walmart" in joe@walmart may be resolved via a search algorithm (e.g. looking up walmart.example.com) or via a different name resolution<=
br>protocol. =3B 

Therefore including this would be dangerous. =3B
>=3B >=3B 3.  In section 2.8=2C if one is expected to use=
 the utf8-realm with a
>=3B >=3B byte-for-byte comparison=2C then on=
e needs to specify a canonicalization of
>=3B >=3B those sub-section=
s of the utf8-realm that are equivalent to A-labels.
>=3B 
>=3B  =
 I am very wary of suggesting that.  The goal for the NAI is to be
>=
=3B agnostic as to A-label or U-label.  Those terms refer to DNS=2C and the=

>=3B utf8-realm is defined independently of DNS.

[BA] Currentl=
y the document suffers from a lack of clarity that I believe was part of th=
e reason for the RFC 4282 debacle. 

The "NAI" can have different rep=
resentations depending on context. =3B RFC 4282 seemed to suffer from t=
he delusion that there is a single unique encoding of the NAI that is valid=
 in every protocol or circumstance. =3B =3B This document needs to =
dispense with that misguided notion early on=2C and make it very clear what=
 the ABNF applies to=2C exactly.

For example=2C an NAI realm contain=
ed in the RADIUS User-Name Attribute will have one representation (canonica=
lized U-labels on the wire) and an NAI realm as used to look up DNS RRs in =
RADIUS Dynamic Discovery will have another representation (e.g. A-labels).&=
nbsp=3B It also will matter if a protocol is 8-bit clean (like EAP and RADI=
US) or requires escaping (SIP or HTTP). 

>=3B >=3B  That
>=
=3B >=3B is "example.com" and "EXAMPLE.COM" should be routed to the same =
location
>=3B >=3B because they are using A-Labels in the utf8-realm=
 while "ex=E1mple.com" and
>=3B >=3B "EX=C1MPLE.COM" (A and uppercas=
e =E1 have the same glyph) are not routed to the
>=3B >=3B same loca=
tion because they are using U-Labels in the utf8-realm.
>=3B 
>=
=3B   That is a good point=2C and one which should be clarified in the docu=
ment.
>=3B 
>=3B   But my take is that "example.com" and "EXAMPLE=
.COM" should be treated
>=3B differently.  i.e. intermediate nodes don=
't know locale=2C and cannot do
>=3B canonicalization.  We might as we=
ll go with that everywhere=2C rather than
>=3B trying to make exceptio=
ns for ASCII.

[BA] The RADIUS Dynamic Discovery document seems to as=
sert that in practice intermediate nodes MAY need to do some canonicalizati=
on. =3B I would like to understand the experience that lies behind that=
 assertion a bit better. =3B For example=2C it is one thing to be refer=
ring to authentication mechanisms that are either only used locally or with=
in EAP tunnel methods (e.g. MS-CHAP)=2C it is another to be referring to wi=
dely deployed implementations that won't comply with the recommendations in=
 this document. =3B For example=2C as far as I know=2C no existing EAP =
implementation applies NFC to the NAI prior to enclosing it in the EAP-Resp=
onse/Identity. =3B As a result=2C it is not realistic to expect the Use=
r-Name to be canonicalized upon entering the AAA system=2C unless we are go=
ing to require the NAS to do the canonicalization (and have some expectatio=
n it will actually happen). 

>=3B   It might be simpler just to sa=
y that the NAI is 8-bit clean=2C and
>=3B therefore avoids the U-label=
 and A-label distinction.

[BA] Stating that the "NAI is 8-bit clean"=
 is very confusing=2C because the NAI realm may be encoded with U-labels or=
 A-labels depending on circumstance. =3B However=2C one can talk about =
"the representation of the NAI within an 8-bit clean protocol". =3B&nbs=
p=3B =3B Let's make sure we do not repeat the mistakes of RFC 4282.&nbs=
p=3B 


>=3B The "utf8-realm" portion of the NAI is intended to =
be compatible with
>=3B Internationalized Domain Names [RFC5890].  As =
defined above=2C the
>=3B "utf8-realm" portion as transported within t=
he RADIUS User-Name
>=3B attribute can transport any valid UTF8 charac=
ter.  There is therefore
>=3B no reason for a NAS to apply the ToAscii=
 function to the "utf8-realm"
>=3B portion of an NAI=2C prior to placi=
ng the NAI into a RADIUS User-Name
>=3B attribute.  Unlike DNS=2C the =
NAI does not make a distinction between
>=3B A-labels and U-labels.
I think the above is still suffering from "RFC4282 disease": =3B c=
onfusion between the NAI and its representation within given protocols.&nbs=
p=3B How about this?

>=3B The "utf8-realm" portion of the NAI is i=
ntended to be compatible with
>=3B Internationalized Domain Names [RFC=
5890].  As defined above=2C the
>=3B "utf8-realm" portion as transport=
ed within an 8-bit clean protocol
>=3B such as RADIUS and EAP can cont=
ain any valid UTF8 character. =3B 
>=3BThere is therefore no reaso=
n for a NAS to apply the ToAscii function to the "utf8-realm"
>=3B por=
tion of an NAI=2C prior to placing the NAI into a RADIUS User-Name
>=
=3B attribute. =3B 


 		 	   		  

=

--_70365518-4e16-41d4-9993-e84bac4290bc_--

From ietf@augustcellars.com  Fri Jan 18 15:07:38 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463CF21F86AE for ; Fri, 18 Jan 2013 15:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.509
X-Spam-Level: 
X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090,  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 PFikeyIC4Jjr for ; Fri, 18 Jan 2013 15:07:37 -0800 (PST)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3A59221F86A2 for ; Fri, 18 Jan 2013 15:07:37 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 21D6038F1B for ; Fri, 18 Jan 2013 15:07:37 -0800 (PST)
From: "Jim Schaad" 
To: 
References: 
In-Reply-To: 
Date: Fri, 18 Jan 2013 15:07:15 -0800
Message-ID: <025601cdf5d0$8ea6c830$abf45890$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac31pV6ATRf6SnhoTUajpfAWVp3AeQAKyIxw
Content-Language: en-us
Subject: [radext] FW: Comments on draft-ietf-radext-nai-01
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, 18 Jan 2013 23:07:38 -0000

Since I used the wrong email address - forwarding

> -----Original Message-----
> From: Jim Schaad [mailto:jimsch@augustcellars.com]
> Sent: Friday, January 18, 2013 11:36 AM
> To: 'draft-ietf-radext-nai@tools.ietf.org'
> Cc: radext@ietf.org
> Subject: Comments on draft-ietf-radext-nai-01
>=20
> Some additional comments to be considered
>=20
> 1.  I like the addition of the term "local" in section 1.1.  I wonder =
if
the
> following text should be added
>=20
> "AAA entities not under the control of the client that "know" the =
locale
may
> have a different concept of that information than the client's =
locale."
>=20
> I understand that this is basically a repeat of what is stated in =
section
2.6, but
> it might be a good addition.
>=20
> 2.  In a follow up to my last set of comments:  Does the working group
feel
> there is any need to remove the restriction that there be at least one =
dot
in a
> utf8-realm.  Given the possibility of new top level domains being =
issued
such
> as "Walmart", what are the odds that those people are going to want to =
be
> able to use a NAI of the form joe@walmart for an NAI?
>=20
> 3.  In section 2.8, if one is expected to use the utf8-realm with a
byte-for-
> byte comparison, then one needs to specify a canonicalization of those
sub-
> sections of the utf8-realm that are equivalent to A-labels.  That is
> "example.com" and "EXAMPLE.COM" should be routed to the same location
> because they are using A-Labels in the utf8-realm while =
"ex=E1mple.com" and
> "EX=C1MPLE.COM" (A and uppercase =E1 have the same glyph) are not =
routed to
> the same location because they are using U-Labels in the utf8-realm.
>=20
> 4.  In section 2.10, my understanding of the DNS terminology is =
different
than
> what is presented here.  In order for it to be a U-Label, the label =
must
have a
> non-ASCII character.  If the section consists only of ASCII characters
then it is
> an A-Label.  This means that the text in the first paragraph is =
incorrect
when
> saying the utf8-realm is not composed of A-labels.  I believe that the
correct
> sentence would be "As defined above, the "utf8-realm" portion as
> transported within the RADIUS User-Name attribute can be composed of
> both U-labels and A-labels."
>=20
> Jim



From ietf@augustcellars.com  Fri Jan 18 15:29:36 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EDC21F8475 for ; Fri, 18 Jan 2013 15:29:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.517
X-Spam-Level: 
X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082,  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 8p1hfLY6YccJ for ; Fri, 18 Jan 2013 15:29:35 -0800 (PST)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id D733421F843A for ; Fri, 18 Jan 2013 15:29:35 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 8484C2C9E7; Fri, 18 Jan 2013 15:29:35 -0800 (PST)
From: "Jim Schaad" 
To: "'Alan DeKok'" 
References: <023601cdf5b2$fa462fe0$eed28fa0$@augustcellars.com> <50F9AEE8.9070105@deployingradius.com>
In-Reply-To: <50F9AEE8.9070105@deployingradius.com>
Date: Fri, 18 Jan 2013 15:29:12 -0800
Message-ID: <025701cdf5d3$a08a1180$e19e3480$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGeKr2aHOFwXSRqsQlSoUSKgYf7RQKjVYlxmJo14PA=
Content-Language: en-us
Cc: radext@ietf.org, draft-ietf-radext-nai@tools.ietf.org
Subject: Re: [radext] Comments on draft-ietf-radext-nai-01
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, 18 Jan 2013 23:29:36 -0000

> -----Original Message-----
> From: Alan DeKok [mailto:aland@deployingradius.com]
> Sent: Friday, January 18, 2013 12:22 PM
> To: Jim Schaad
> Cc: draft-ietf-radext-nai@tools.ietf.org; radext@ietf.org
> Subject: Re: Comments on draft-ietf-radext-nai-01
>=20
> Jim Schaad wrote:
> > Some additional comments to be considered
> >
> > 1.  I like the addition of the term "local" in section 1.1.  I =
wonder
> > if the following text should be added
> >
> > "AAA entities not under the control of the client that "know" the
> > locale may have a different concept of that information than the =
client's
> locale."
>=20
>   Sounds good to me.  That sounds a little convoluted to me.  I'll =
rephrase it
> as:
>=20
> The client which "knows" the locale may have a different concept of =
this text
> than other AAA entities, which do not know the locale.

Doesn't quite have the same meaning.  But yes it is better than what I =
wrote.  Perhaps add =20

which do not "know" the same locale.

>=20
> > 2.  In a follow up to my last set of comments:  Does the working =
group
> > feel there is any need to remove the restriction that there be at
> > least one dot in a utf8-realm.  Given the possibility of new top =
level
> > domains being issued such as "Walmart", what are the odds that those
> > people are going to want to be able to use a NAI of the form =
joe@walmart
> for an NAI?
>=20
>   My $0.02 is that allowing top-level domains as the NAI is =
problematic, and
> not in line with historical practice.
>=20
>   But... I can see people asking for it.
>=20
> > 3.  In section 2.8, if one is expected to use the utf8-realm with a
> > byte-for-byte comparison, then one needs to specify a =
canonicalization
> > of those sub-sections of the utf8-realm that are equivalent to =
A-labels.
>=20
>   I am very wary of suggesting that.  The goal for the NAI is to be =
agnostic as
> to A-label or U-label.  Those terms refer to DNS, and the utf8-realm =
is
> defined independently of DNS.
>=20
> >  That
> > is "example.com" and "EXAMPLE.COM" should be routed to the same
> > location because they are using A-Labels in the utf8-realm while
> > "example.com" and "EX?MPLE.COM" (A and uppercase a have the same
> > glyph) are not routed to the same location because they are using =
U-Labels
> in the utf8-realm.

Somewhere my Greek alphas seem to have gotten lost.
>=20
>   That is a good point, and one which should be clarified in the =
document.
>=20
>   But my take is that "example.com" and "EXAMPLE.COM" should be =
treated
> differently.  i.e. intermediate nodes don't know locale, and cannot do
> canonicalization.  We might as well go with that everywhere, rather =
than
> trying to make exceptions for ASCII.

I am worried about this for two reasons, first I don't believe that it =
will conform to current practice.  I think that currently proxies would =
route based on a DNS version of the name - which would be agnostic =
relative to case.  Second, you are now having a major difference with =
e-mail addresses which will case-fold A-labels when doing MX record =
lookups and thus the  EXAMPLE.com and example.com are going to be the =
same.

You should have a better idea on the first worry, the second one needs =
to be documented if we are sticking with this.

>=20
> > 4.  In section 2.10, my understanding of the DNS terminology is
> > different than what is presented here.  In order for it to be a
> > U-Label, the label must have a non-ASCII character.  If the section
> > consists only of ASCII characters then it is an A-Label.  This means
> > that the text in the first paragraph is incorrect when saying the
> > utf8-realm is not composed of A-labels.
>=20
>   Well.. the utf8-realm can be entirely U-labels, and does not need to =
be A-
> labels.
>=20
> >  I believe that the correct sentence would be "As defined above, the
> > "utf8-realm" portion as transported within the RADIUS User-Name
> > attribute can be composed of both U-labels and A-labels."
>=20
>   It might be simpler just to say that the NAI is 8-bit clean, and =
therefore
> avoids the U-label and A-label distinction.
>=20
>   How about this:
>=20
>=20
> The "utf8-realm" portion of the NAI is intended to be compatible with
> Internationalized Domain Names [RFC5890].  As defined above, the =
"utf8-
> realm" portion as transported within the RADIUS User-Name attribute =
can
> transport any valid UTF8 character.  There is therefore no reason for =
a NAS to
> apply the ToAscii function to the "utf8-realm"
> portion of an NAI, prior to placing the NAI into a RADIUS User-Name
> attribute.  Unlike DNS, the NAI does not make a distinction between =
A-labels
> and U-labels.
>=20
>   Alan DeKok.


From ietf@augustcellars.com  Fri Jan 18 15:42:57 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED5A21F8440 for ; Fri, 18 Jan 2013 15:42:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.523
X-Spam-Level: 
X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HSQ-Fp1l7uRJ for ; Fri, 18 Jan 2013 15:42:53 -0800 (PST)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD5521F843F for ; Fri, 18 Jan 2013 15:42:53 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id B1E832CA02; Fri, 18 Jan 2013 15:42:51 -0800 (PST)
From: "Jim Schaad" 
To: "'Bernard Aboba'" , "'Alan DeKok'" 
References: <023601cdf5b2$fa462fe0$eed28fa0$@augustcellars.com>, <50F9AEE8.9070105@deployingradius.com> 
In-Reply-To: 
Date: Fri, 18 Jan 2013 15:42:27 -0800
Message-ID: <027601cdf5d5$7b8511d0$728f3570$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0277_01CDF592.6D635870"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGeKr2aHOFwXSRqsQlSoUSKgYf7RQKjVYlxAdLczliYi6A3UA==
Content-Language: en-us
Cc: radext@ietf.org, draft-ietf-radext-nai@tools.ietf.org
Subject: Re: [radext] Comments on draft-ietf-radext-nai-01
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, 18 Jan 2013 23:42:57 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0277_01CDF592.6D635870
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable

=20

=20

From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20
Sent: Friday, January 18, 2013 1:10 PM
To: Alan DeKok; Jim Schaad
Cc: radext@ietf.org; draft-ietf-radext-nai@tools.ietf.org
Subject: RE: [radext] Comments on draft-ietf-radext-nai-01

=20

=20

> > 2. In a follow up to my last set of comments: Does the working group
feel
> > there is any need to remove the restriction that there be at least =
one
dot
> > in a utf8-realm. Given the possibility of new top level domains =
being
> > issued such as "Walmart", what are the odds that those people are =
going
to
> > want to be able to use a NAI of the form joe@walmart for an NAI?
> My $0.02 is that allowing top-level domains as the NAI is problematic,
> and not in line with historical practice.

[BA] I agree.  RFC 1536 is very clear that a single label has a locally
defined meaning.=20

That is, "walmart" in joe@walmart may be resolved via a search algorithm =

(e.g. looking up walmart.example.com) or via a different name resolution
protocol. =20

Therefore including this would be dangerous.

[JLS] If we are saying this, then are we also saying that we never =
expect
joe@walmart to become a valid e-mail address as well.  With the advent =
of
issuing new TLDs it is quite possible that RFC 1536 needs to be updated =
to
reflect the new reality.
=20
> > 3. In section 2.8, if one is expected to use the utf8-realm with a
> > byte-for-byte comparison, then one needs to specify a =
canonicalization
of
> > those sub-sections of the utf8-realm that are equivalent to =
A-labels.
>=20
> I am very wary of suggesting that. The goal for the NAI is to be
> agnostic as to A-label or U-label. Those terms refer to DNS, and the
> utf8-realm is defined independently of DNS.

[BA] Currently the document suffers from a lack of clarity that I =
believe
was part of the reason for the RFC 4282 debacle.=20

The "NAI" can have different representations depending on context.  RFC =
4282
seemed to suffer from the delusion that there is a single unique =
encoding of
the NAI that is valid in every protocol or circumstance.   This document
needs to dispense with that misguided notion early on, and make it very
clear what the ABNF applies to, exactly.

For example, an NAI realm contained in the RADIUS User-Name Attribute =
will
have one representation (canonicalized U-labels on the wire) and an NAI
realm as used to look up DNS RRs in RADIUS Dynamic Discovery will have
another representation (e.g. A-labels).  It also will matter if a =
protocol
is 8-bit clean (like EAP and RADIUS) or requires escaping (SIP or HTTP). =


[JLS]  Again - the language of canonicalized U-Label is incorrect.   =
Quoting
from  RFC 5890

A "U-label" is an IDNA-valid string of Unicode characters, in

      Normalization Form C (NFC) and including at least one non-ASCII

      character,

=20

A more correct term is going to be it is an "IDNA-valid" label. (Also =
from
RFC 5890).

> > That
> > is "example.com" and "EXAMPLE.COM" should be routed to the same =
location
> > because they are using A-Labels in the utf8-realm while =
"ex=E1mple.com"
and
> > "EX=C1MPLE.COM" (A and uppercase =E1 have the same glyph) are not =
routed to
the
> > same location because they are using U-Labels in the utf8-realm.
>=20
> That is a good point, and one which should be clarified in the =
document.
>=20
> But my take is that "example.com" and "EXAMPLE.COM" should be treated
> differently. i.e. intermediate nodes don't know locale, and cannot do
> canonicalization. We might as well go with that everywhere, rather =
than
> trying to make exceptions for ASCII.

[BA] The RADIUS Dynamic Discovery document seems to assert that in =
practice
intermediate nodes MAY need to do some canonicalization.  I would like =
to
understand the experience that lies behind that assertion a bit better.  =
For
example, it is one thing to be referring to authentication mechanisms =
that
are either only used locally or within EAP tunnel methods (e.g. =
MS-CHAP), it
is another to be referring to widely deployed implementations that won't
comply with the recommendations in this document.  For example, as far =
as I
know, no existing EAP implementation applies NFC to the NAI prior to
enclosing it in the EAP-Response/Identity.  As a result, it is not =
realistic
to expect the User-Name to be canonicalized upon entering the AAA =
system,
unless we are going to require the NAS to do the canonicalization (and =
have
some expectation it will actually happen).=20

=20

[JLS] But even having the NAS do it may lead to problems.  My client and =
the
NAS might have different ideas of what the locale is and thus would
canonicalize it differently.  I think that this MUST be pushed onto the
clients and not the NAS in order to get it to work correctly. =20



> It might be simpler just to say that the NAI is 8-bit clean, and
> therefore avoids the U-label and A-label distinction.

[BA] Stating that the "NAI is 8-bit clean" is very confusing, because =
the
NAI realm may be encoded with U-labels or A-labels depending on
circumstance.  However, one can talk about "the representation of the =
NAI
within an 8-bit clean protocol".    Let's make sure we do not repeat the
mistakes of RFC 4282. =20



Say that the utf8-real is IDNA-valid avoids the U-label/A-label =
distinction
while making it clear that it is an 8-bit label.



> The "utf8-realm" portion of the NAI is intended to be compatible with
> Internationalized Domain Names [RFC5890]. As defined above, the
> "utf8-realm" portion as transported within the RADIUS User-Name
> attribute can transport any valid UTF8 character. There is therefore
> no reason for a NAS to apply the ToAscii function to the "utf8-realm"
> portion of an NAI, prior to placing the NAI into a RADIUS User-Name
> attribute. Unlike DNS, the NAI does not make a distinction between
> A-labels and U-labels.

I think the above is still suffering from "RFC4282 disease":  confusion
between the NAI and its representation within given protocols.  How =
about
this?

> The "utf8-realm" portion of the NAI is intended to be compatible with
> Internationalized Domain Names [RFC5890]. As defined above, the
> "utf8-realm" portion as transported within an 8-bit clean protocol
> such as RADIUS and EAP can contain any valid UTF8 character. =20
>There is therefore no reason for a NAS to apply the ToAscii function to =
the
"utf8-realm"
> portion of an NAI, prior to placing the NAI into a RADIUS User-Name
> attribute. =20




------=_NextPart_000_0277_01CDF592.6D635870
Content-Type: text/html;
	charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable


 
 
From:=
 =
Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
Sent: =
Friday, January 18, 2013 1:10 PM
To: Alan DeKok; Jim =
Schaad
Cc: radext@ietf.org; =
draft-ietf-radext-nai@tools.ietf.org
Subject: RE: [radext] =
Comments on draft-ietf-radext-nai-01
 
 
=

> > 2. In a follow up =
to my last set of comments: Does the working group feel
> > =
there is any need to remove the restriction that there be at least one =
dot
> > in a utf8-realm. Given the possibility of new top level =
domains being
> > issued such as "Walmart", what are =
the odds that those people are going to
> > want to be able to =
use a NAI of the form joe@walmart for an NAI?
> My $0.02 is that =
allowing top-level domains as the NAI is problematic,
> and not in =
line with historical practice.

[BA] I agree.  RFC 1536 is =
very clear that a single label has a locally defined meaning. =


That is, "walmart" in joe@walmart may be resolved via =
a search algorithm 
(e.g. looking up walmart.example.com) or via a =
different name resolution
protocol.  

Therefore including =
this would be dangerous.
[JLS] If we =
are saying this, then are we also saying that we never expect =
joe@walmart to become a valid e-mail address as well.=A0 With the advent =
of issuing new TLDs it is quite possible that RFC 1536 needs to be =
updated to reflect the new reality.
 
> > 3. =
In section 2.8, if one is expected to use the utf8-realm with a
> =
> byte-for-byte comparison, then one needs to specify a =
canonicalization of
> > those sub-sections of the utf8-realm =
that are equivalent to A-labels.
> 
> I am very wary of =
suggesting that. The goal for the NAI is to be
> agnostic as to =
A-label or U-label. Those terms refer to DNS, and the
> utf8-realm =
is defined independently of DNS.

[BA] Currently the document =
suffers from a lack of clarity that I believe was part of the reason for =
the RFC 4282 debacle. 

The "NAI" can have different =
representations depending on context.  RFC 4282 seemed to suffer =
from the delusion that there is a single unique encoding of the NAI that =
is valid in every protocol or circumstance.   This document =
needs to dispense with that misguided notion early on, and make it very =
clear what the ABNF applies to, exactly.

For example, an NAI =
realm contained in the RADIUS User-Name Attribute will have one =
representation (canonicalized U-labels on the wire) and an NAI realm as =
used to look up DNS RRs in RADIUS Dynamic Discovery will have another =
representation (e.g. A-labels).  It also will matter if a protocol =
is 8-bit clean (like EAP and RADIUS) or requires escaping (SIP or HTTP). =

[JLS]=A0 Again – the language of canonicalized U-Label is =
incorrect.=A0=A0 Quoting from=A0 RFC 5890
A "U-label" is an IDNA-valid string of Unicode =
characters, in
=A0=A0=A0=A0=A0 =
Normalization Form C (NFC) and including at least one =
non-ASCII
=A0=A0=A0=A0=A0 =
character,
 
A more correct term =
is going to be it is an “IDNA-valid” label. (Also from RFC =
5890).

> > =
That
> > is "example.com" and "EXAMPLE.COM" =
should be routed to the same location
> > because they are =
using A-Labels in the utf8-realm while "ex=E1mple.com" =
and
> > "EX=C1MPLE.COM" (A and uppercase =E1 have the =
same glyph) are not routed to the
> > same location because =
they are using U-Labels in the utf8-realm.
> 
> That is a =
good point, and one which should be clarified in the document.
> =

> But my take is that "example.com" and =
"EXAMPLE.COM" should be treated
> differently. i.e. =
intermediate nodes don't know locale, and cannot do
> =
canonicalization. We might as well go with that everywhere, rather =
than
> trying to make exceptions for ASCII.

[BA] The RADIUS =
Dynamic Discovery document seems to assert that in practice intermediate =
nodes MAY need to do some canonicalization.  I would like to =
understand the experience that lies behind that assertion a bit =
better.  For example, it is one thing to be referring to =
authentication mechanisms that are either only used locally or within =
EAP tunnel methods (e.g. MS-CHAP), it is another to be referring to =
widely deployed implementations that won't comply with the =
recommendations in this document.  For example, as far as I know, =
no existing EAP implementation applies NFC to the NAI prior to enclosing =
it in the EAP-Response/Identity.  As a result, it is not realistic =
to expect the User-Name to be canonicalized upon entering the AAA =
system, unless we are going to require the NAS to do the =
canonicalization (and have some expectation it will actually happen). =

 
[JLS] But even having the NAS do it may lead to problems.=A0 My =
client and the NAS might have different ideas of what the locale is and =
thus would canonicalize it differently. =A0I think that this MUST be =
pushed onto the clients and not the NAS in order to get it to work =
correctly.=A0 


> It might be =
simpler just to say that the NAI is 8-bit clean, and
> therefore =
avoids the U-label and A-label distinction.

[BA] Stating that the =
"NAI is 8-bit clean" is very confusing, because the NAI realm =
may be encoded with U-labels or A-labels depending on =
circumstance.  However, one can talk about "the representation =
of the NAI within an 8-bit clean protocol".    Let's =
make sure we do not repeat the mistakes of RFC 4282.  

Say that the utf8-real is IDNA-valid avoids the U-label/A-label =
distinction while making it clear that it is an 8-bit =
label.


> The =
"utf8-realm" portion of the NAI is intended to be compatible =
with
> Internationalized Domain Names [RFC5890]. As defined above, =
the
> "utf8-realm" portion as transported within the =
RADIUS User-Name
> attribute can transport any valid UTF8 =
character. There is therefore
> no reason for a NAS to apply the =
ToAscii function to the "utf8-realm"
> portion of an =
NAI, prior to placing the NAI into a RADIUS User-Name
> attribute. =
Unlike DNS, the NAI does not make a distinction between
> A-labels =
and U-labels.

I think the above is still suffering from =
"RFC4282 disease":  confusion between the NAI and its =
representation within given protocols.  How about this?

> =
The "utf8-realm" portion of the NAI is intended to be =
compatible with
> Internationalized Domain Names [RFC5890]. As =
defined above, the
> "utf8-realm" portion as transported =
within an 8-bit clean protocol
> such as RADIUS and EAP can =
contain any valid UTF8 character.  
>There is therefore no =
reason for a NAS to apply the ToAscii function to the =
"utf8-realm"
> portion of an NAI, prior to placing the =
NAI into a RADIUS User-Name
> attribute.  =



------=_NextPart_000_0277_01CDF592.6D635870--


From bernard_aboba@hotmail.com  Fri Jan 18 16:01:49 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E92321F872C for ; Fri, 18 Jan 2013 16:01:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.218
X-Spam-Level: 
X-Spam-Status: No, score=-102.218 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 K637yXKdsOWt for ; Fri, 18 Jan 2013 16:01:48 -0800 (PST)
Received: from blu0-omc4-s26.blu0.hotmail.com (blu0-omc4-s26.blu0.hotmail.com [65.55.111.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5203B21F870E for ; Fri, 18 Jan 2013 16:01:48 -0800 (PST)
Received: from BLU002-W127 ([65.55.111.137]) by blu0-omc4-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 18 Jan 2013 16:01:47 -0800
X-EIP: [s55aCaIdBXOtSx/gBY5+3kcUI7Y91otS]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_093f1fde-a667-471c-91c5-a98a20acf1be_"
From: Bernard Aboba 
To: Jim Schaad , Alan DeKok 
Date: Fri, 18 Jan 2013 16:01:47 -0800
Importance: Normal
In-Reply-To: <027601cdf5d5$7b8511d0$728f3570$@augustcellars.com>
References: <023601cdf5b2$fa462fe0$eed28fa0$@augustcellars.com>, , <50F9AEE8.9070105@deployingradius.com>, , <027601cdf5d5$7b8511d0$728f3570$@augustcellars.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Jan 2013 00:01:47.0811 (UTC) FILETIME=[2CDE2730:01CDF5D8]
Cc: "radext@ietf.org" , "draft-ietf-radext-nai@tools.ietf.org" 
Subject: Re: [radext] Comments on draft-ietf-radext-nai-01
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: Sat, 19 Jan 2013 00:01:49 -0000

--_093f1fde-a667-471c-91c5-a98a20acf1be_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

[JLS] If we are saying this=2C then are we also saying that we never expect=
 joe@walmart to become a valid e-mail address as well.  With the advent of =
issuing new TLDs it is quite possible that RFC 1536 needs to be updated to =
reflect the new reality.
[BA] As I understand it=2C ICANN is looking at drafting guidelines that wou=
ld prohibit hosting of A/AAAA=2C SRV=2C etc. RRs in TLDs=2C so there is no =
need to go there.=20
 \[JLS]  Again =96 the language of canonicalized U-Label is incorrect.   Qu=
oting from  RFC 5890A "U-label" is an IDNA-valid string of Unicode characte=
rs=2C in      Normalization Form C (NFC) and including at least one non-ASC=
II      character=2C A more correct term is going to be it is an =93IDNA-va=
lid=94 label. (Also from RFC 5890).
[BA] OK.  The question remains whether an NAI realm received from an 8-bit =
clean client (e.g. an EAP supplicant) will necessarily contains "IDNA-valid=
" labels.  The RADIUS Dynamic Discovery document says "no" -- and AFAIK=2C =
no existing EAP implementations utilize NFC=2C so that is correct.  [JLS] B=
ut even having the NAS do it may lead to problems.  My client and the NAS m=
ight have different ideas of what the locale is and thus would canonicalize=
 it differently.  I think that this MUST be pushed onto the clients and not=
 the NAS in order to get it to work correctly. =20

[BA] Assuming that the client converts the NAI to UTF-8 before sending it=
=2C does this problem really exist?  The NFC algorithm does not require kno=
wledge of the locale=2C right?=20

Say that the utf8-real is IDNA-valid avoids the U-label/A-label distinction=
 while making it clear that it is an 8-bit label.
[BA] The problem that the NAI realm output by the client may not be IDNA-va=
lid=2C even if it is in UTF-8=2C and adding "MUST" to this document won't m=
ake it so.=20
 		 	   		  =

--_093f1fde-a667-471c-91c5-a98a20acf1be_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable





=

[JLS] If we are saying this=2C then are we also saying that we never ex=
pect joe@walmart to become a valid e-mail address as well. =3B With the=
 advent of issuing new TLDs it is quite possible that RFC 1536 needs to be =
updated to reflect the new reality.

[BA] As I understand it=
=2C ICANN is looking at drafting guidelines that would prohibit hosting of =
A/AAAA=2C SRV=2C etc. RRs in TLDs=2C so there is no need to go there. 
<=
/span>
&n=
bsp=3B\
[JLS] =3B Again =96 the language of canonicalized U-Label is incorre=
ct. =3B =3B Quoting from =3B RFC 5890
A "U-label" is an IDNA-valid string of Unicode characters=2C in<=
/span>
 =3B =3B =3B =3B =
=3B Normalization Form C (NFC) and including at least one non-ASCII<=
/p>
 =3B =3B =3B =3B =3B chara=
cter=2C
 =3B
A more correct term is going to be it is an =93IDNA-valid=94 =
label. (Also from RFC 5890).

[BA] OK. =3B Th=
e question remains whether an NAI realm received from an 8-bit clean client=
 (e.g. an EAP supplicant) will necessarily contains "IDNA-valid" labels.&nb=
sp=3B The RADIUS Dynamic Discovery document says "no" -- and AFAIK=2C no ex=
isting EAP implementations utilize NFC=2C so that is correct. 
<=
span style=3D"font-size:11.0pt=3Bfont-family:"=3BCalibri"=3B=2C&quo=
t=3Bsans-serif"=3B=3Bcolor:#1F497D"> =3B
[JLS] But even having th=
e NAS do it may lead to problems. =3B My client and the NAS might have =
different ideas of what the locale is and thus would canonicalize it differ=
ently.  =3BI think that this MUST be pushed onto the clients and not th=
e NAS in order to get it to work correctly. =3B 

[BA] Assuming that the client converts the NAI t=
o UTF-8 before sending it=2C does this problem really exist? =3B The NF=
C algorithm does not require knowledge of the locale=2C right? 

Say that the utf8-real is ID=
NA-valid avoids the U-label/A-label distinction while making it clear that =
it is an 8-bit label.

[BA] Th=
e problem that the NAI realm output by the client may not be IDNA-valid=2C =
even if it is in UTF-8=2C and adding "MUST" to this document won't make it =
so. 
 		 	   		  

=

--_093f1fde-a667-471c-91c5-a98a20acf1be_--

From ietf@augustcellars.com  Fri Jan 18 16:20:37 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9542A21F86CA for ; Fri, 18 Jan 2013 16:20:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.529
X-Spam-Level: 
X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MgS5-UorvZeR for ; Fri, 18 Jan 2013 16:20:35 -0800 (PST)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5DA821F86C4 for ; Fri, 18 Jan 2013 16:20:35 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 7048E2CA02; Fri, 18 Jan 2013 16:20:35 -0800 (PST)
From: "Jim Schaad" 
To: "'Bernard Aboba'" , "'Alan DeKok'" 
References: <023601cdf5b2$fa462fe0$eed28fa0$@augustcellars.com>, , <50F9AEE8.9070105@deployingradius.com>, , <027601cdf5d5$7b8511d0$728f3570$@augustcellars.com> 
In-Reply-To: 
Date: Fri, 18 Jan 2013 16:20:12 -0800
Message-ID: <028101cdf5da$c059aaf0$410d00d0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0282_01CDF597.B2375550"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGeKr2aHOFwXSRqsQlSoUSKgYf7RQKjVYlxAdLczlgCFW4Q0AJ7JleKmGcn9IA=
Content-Language: en-us
Cc: radext@ietf.org, draft-ietf-radext-nai@tools.ietf.org
Subject: Re: [radext] Comments on draft-ietf-radext-nai-01
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: Sat, 19 Jan 2013 00:20:37 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0282_01CDF597.B2375550
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I am unsure that NFC is locale agnostic or not.  For some reason in the back
of my head there is a note that says it is not, but I don't have a reference
for this note at the current time. 

 

From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
Sent: Friday, January 18, 2013 4:02 PM
To: Jim Schaad; Alan DeKok
Cc: radext@ietf.org; draft-ietf-radext-nai@tools.ietf.org
Subject: RE: [radext] Comments on draft-ietf-radext-nai-01

 

[JLS] If we are saying this, then are we also saying that we never expect
joe@walmart to become a valid e-mail address as well.  With the advent of
issuing new TLDs it is quite possible that RFC 1536 needs to be updated to
reflect the new reality.

 

[BA] As I understand it, ICANN is looking at drafting guidelines that would
prohibit hosting of A/AAAA, SRV, etc. RRs in TLDs, so there is no need to go
there. 

 \

[JLS]  Again - the language of canonicalized U-Label is incorrect.   Quoting
from  RFC 5890

A "U-label" is an IDNA-valid string of Unicode characters, in

      Normalization Form C (NFC) and including at least one non-ASCII

      character,

 

A more correct term is going to be it is an "IDNA-valid" label. (Also from
RFC 5890).

 

[BA] OK.  The question remains whether an NAI realm received from an 8-bit
clean client (e.g. an EAP supplicant) will necessarily contains "IDNA-valid"
labels.  The RADIUS Dynamic Discovery document says "no" -- and AFAIK, no
existing EAP implementations utilize NFC, so that is correct. 

 

[JLS] But even having the NAS do it may lead to problems.  My client and the
NAS might have different ideas of what the locale is and thus would
canonicalize it differently.  I think that this MUST be pushed onto the
clients and not the NAS in order to get it to work correctly.  

 

[BA] Assuming that the client converts the NAI to UTF-8 before sending it,
does this problem really exist?  The NFC algorithm does not require
knowledge of the locale, right? 

 

Say that the utf8-real is IDNA-valid avoids the U-label/A-label distinction
while making it clear that it is an 8-bit label.


[BA] The problem that the NAI realm output by the client may not be
IDNA-valid, even if it is in UTF-8, and adding "MUST" to this document won't
make it so. 


------=_NextPart_000_0282_01CDF597.B2375550
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I am unsure that NFC is locale agnostic or not.  For some reason =
in the back of my head there is a note that says it is not, but I =
don’t have a reference for this note at the current time. =

 
From:=
 =
Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
Sent: =
Friday, January 18, 2013 4:02 PM
To: Jim Schaad; Alan =
DeKok
Cc: radext@ietf.org; =
draft-ietf-radext-nai@tools.ietf.org
Subject: RE: [radext] =
Comments on draft-ietf-radext-nai-01
 
[JLS] If we =
are saying this, then are we also saying that we never expect =
joe@walmart to become a valid e-mail address as well.  With the =
advent of issuing new TLDs it is quite possible that RFC 1536 needs to =
be updated to reflect the new reality.
 
=

[BA] As I understand it, =
ICANN is looking at drafting guidelines that would prohibit hosting of =
A/AAAA, SRV, etc. RRs in TLDs, so there is no need to go there. =

 \
[JLS]  Again – the language of canonicalized U-Label is =
incorrect.   Quoting from  RFC 5890
A "U-label" is an IDNA-valid string of Unicode =
characters, in
      Normalization Form C (NFC) and =
including at least one non-ASCII
      character,
 
A more correct term is going to be it is an =
“IDNA-valid” label. (Also from RFC 5890).
 
=

[BA] OK.  The question =
remains whether an NAI realm received from an 8-bit clean client (e.g. =
an EAP supplicant) will necessarily contains "IDNA-valid" =
labels.  The RADIUS Dynamic Discovery document says "no" =
-- and AFAIK, no existing EAP implementations utilize NFC, so that is =
correct. 
 
[JLS] But even having the NAS do it may lead to problems.  My =
client and the NAS might have different ideas of what the locale is and =
thus would canonicalize it differently.  I think that this MUST be =
pushed onto the clients and not the NAS in order to get it to work =
correctly.  
 
=

[BA] Assuming that the =
client converts the NAI to UTF-8 before sending it, does this problem =
really exist?  The NFC algorithm does not require knowledge of the =
locale, right? 
 
=

Say that the utf8-real is IDNA-valid avoids the U-label/A-label =
distinction while making it clear that it is an 8-bit label.

[BA] The problem that =
the NAI realm output by the client may not be IDNA-valid, even if it is =
in UTF-8, and adding "MUST" to this document won't make it so. =


------=_NextPart_000_0282_01CDF597.B2375550--


From aland@deployingradius.com  Sat Jan 19 06:52:50 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027DC21F8413 for ; Sat, 19 Jan 2013 06:52:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.511
X-Spam-Level: 
X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 83YxhvYWQ88O for ; Sat, 19 Jan 2013 06:52:49 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 17BA721F8419 for ; Sat, 19 Jan 2013 06:52:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 70F242240850; Sat, 19 Jan 2013 15:52:00 +0100 (CET)
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 oJ4tBGTdcjDS; Sat, 19 Jan 2013 15:51:59 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 33E0422405E9; Sat, 19 Jan 2013 15:51:59 +0100 (CET)
Message-ID: <50FAB30E.4040002@deployingradius.com>
Date: Sat, 19 Jan 2013 09:51:58 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Bernard Aboba 
References: <023601cdf5b2$fa462fe0$eed28fa0$@augustcellars.com>, <50F9AEE8.9070105@deployingradius.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "radext@ietf.org" , Jim Schaad , "draft-ietf-radext-nai@tools.ietf.org" 
Subject: Re: [radext] Comments on draft-ietf-radext-nai-01
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: Sat, 19 Jan 2013 14:52:50 -0000

Bernard Aboba wrote:
> That is, "walmart" in joe@walmart may be resolved via a search algorithm
> (e.g. looking up walmart.example.com) or via a different name resolution
> protocol. 
> 
> Therefore including this would be dangerous.

  Good point.  I'll add a note to that effect.

> The "NAI" can have different representations depending on context.  RFC
> 4282 seemed to suffer from the delusion that there is a single unique
> encoding of the NAI that is valid in every protocol or circumstance.  
> This document needs to dispense with that misguided notion early on, and
> make it very clear what the ABNF applies to, exactly.

  Yes.  The NAI is defined independently of any protocol.

> For example, an NAI realm contained in the RADIUS User-Name Attribute
> will have one representation (canonicalized U-labels on the wire) and an
> NAI realm as used to look up DNS RRs in RADIUS Dynamic Discovery will
> have another representation (e.g. A-labels).  It also will matter if a
> protocol is 8-bit clean (like EAP and RADIUS) or requires escaping (SIP
> or HTTP).

  The document contains a new section: Compatibility with other
protocols.  That section discusses the *transport* of the NAI within
other protocols.  The transported version must follow the requirements
of the other protocols.  e.g. "." --> %2E.  The resulting string is
*not* the NAI.

  Something similar should be said early in the document, too.

> [BA] The RADIUS Dynamic Discovery document seems to assert that in
> practice intermediate nodes MAY need to do some canonicalization.  I
> would like to understand the experience that lies behind that assertion
> a bit better.  For example, it is one thing to be referring to
> authentication mechanisms that are either only used locally or within
> EAP tunnel methods (e.g. MS-CHAP), it is another to be referring to
> widely deployed implementations that won't comply with the
> recommendations in this document.  For example, as far as I know, no
> existing EAP implementation applies NFC to the NAI prior to enclosing it
> in the EAP-Response/Identity.  As a result, it is not realistic to
> expect the User-Name to be canonicalized upon entering the AAA system,
> unless we are going to require the NAS to do the canonicalization (and
> have some expectation it will actually happen).

  I don't think that will happen.  But I *would* encourage the
canonicalization of the identity prior to it entering the AAA system.

  I've discussed the issue with implementors of EAP supplicants.  Their
consensus is largely to avoid the issue.  They want to treat the
identity as an opaque token that they are given.  They may not have
access to locale information in order to normalize it.

>> It might be simpler just to say that the NAI is 8-bit clean, and
>> therefore avoids the U-label and A-label distinction.
> 
> [BA] Stating that the "NAI is 8-bit clean" is very confusing, because
> the NAI realm may be encoded with U-labels or A-labels depending on
> circumstance.  However, one can talk about "the representation of the
> NAI within an 8-bit clean protocol".    Let's make sure we do not repeat
> the mistakes of RFC 4282. 

  Text:

Where a protocol is 8-bit clean, it can likely transport the NAI
as-is, without further modification.

Where a protocol is not 8-bit clean, it MUST NOT affect the definition
or handling of the NAI.  That is, if a protocol escapes the '.'
character as "%2E", then the protocol may have an identifier
transported as "fred@example%2Ecom", whereas the NAI for that user is
"fred@example.com".  Any comparison, validation, or use of the NAI
MUST be done on its un-escaped (i.e. utf8-clean) form.


> I think the above is still suffering from "RFC4282 disease":  confusion
> between the NAI and its representation within given protocols.  How
> about this?
> 
>> The "utf8-realm" portion of the NAI is intended to be compatible with
>> Internationalized Domain Names [RFC5890]. As defined above, the
>> "utf8-realm" portion as transported within an 8-bit clean protocol
>> such as RADIUS and EAP can contain any valid UTF8 character. 
>>There is therefore no reason for a NAS to apply the ToAscii function to
> the "utf8-realm"
>> portion of an NAI, prior to placing the NAI into a RADIUS User-Name
>> attribute. 

  Looks good to me.

  Alan DeKok.

From aland@deployingradius.com  Sat Jan 19 07:04:14 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF04121F8456 for ; Sat, 19 Jan 2013 07:04:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level: 
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 P-QjA1shm7g6 for ; Sat, 19 Jan 2013 07:04:13 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id BAD5F21F8438 for ; Sat, 19 Jan 2013 07:04:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 7563122405E9; Sat, 19 Jan 2013 16:00:22 +0100 (CET)
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 KDLB-AKz8wuf; Sat, 19 Jan 2013 16:00:22 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id A1F092240850; Sat, 19 Jan 2013 16:00:21 +0100 (CET)
Message-ID: <50FAB504.8020609@deployingradius.com>
Date: Sat, 19 Jan 2013 10:00:20 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Jim Schaad 
References: <023601cdf5b2$fa462fe0$eed28fa0$@augustcellars.com> <50F9AEE8.9070105@deployingradius.com> <025701cdf5d3$a08a1180$e19e3480$@augustcellars.com>
In-Reply-To: <025701cdf5d3$a08a1180$e19e3480$@augustcellars.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: radext@ietf.org, draft-ietf-radext-nai@tools.ietf.org
Subject: Re: [radext] Comments on draft-ietf-radext-nai-01
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: Sat, 19 Jan 2013 15:04:15 -0000

Jim Schaad wrote:
> Doesn't quite have the same meaning.  But yes it is better than what I wrote.  Perhaps add  
> 
> which do not "know" the same locale.

  Done.

> Somewhere my Greek alphas seem to have gotten lost.

  Yes... highlighting the problem of i18n.

>> [ re: example.com != EXAMPLE.COM ]
>
> I am worried about this for two reasons, first I don't believe that it will conform to current practice.

  Some systems do case insensitive matching.  Others don't.  Some
explicitly reject wrong-case logins.

>  I think that currently proxies would route based on a DNS version of the name - which would be agnostic relative to case. 

  Yes, but (to be pedantic), that's a DNS problem.

	DNS (example.com) = X
	DNS (EXAMPLE.COM) = Y

  Maybe X==Y.  That's nice, but it's really an issue for the realm.

  I see this distinction as causing problems.  (i.e. I've seen similar
distinctions cause issues in other contexts).  To be very clear:

  The NAI is *input* to DNS.  The *output* of DNS may be the same, even
if a "bit compare" of input NAIs is different.  That *output* has no
bearing on the NAI.  It doesn't mean you can say comparisons of the NAI
are "case insensitive".

> Second, you are now having a major difference with e-mail addresses which will case-fold A-labels when doing MX record lookups and thus the  EXAMPLE.com and example.com are going to be the same.

  That's again a DNS issue.  The output of DNS doesn't affect the
definition of the NAI.  And email already allows for folding and
non-folding whitespace, which isn't allowed in the NAI.

> You should have a better idea on the first worry, the second one needs to be documented if we are sticking with this.

  It should be clarified, yes.

  Alan DeKok.

From aland@deployingradius.com  Sat Jan 19 07:18:28 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6EE21F8488 for ; Sat, 19 Jan 2013 07:18:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.522
X-Spam-Level: 
X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 Gc6wEYEKIezW for ; Sat, 19 Jan 2013 07:18:27 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 789E521F8487 for ; Sat, 19 Jan 2013 07:18:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 1246B2240850; Sat, 19 Jan 2013 16:18:27 +0100 (CET)
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 h0lDjze-3x9k; Sat, 19 Jan 2013 16:18:26 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 167C722405E9; Sat, 19 Jan 2013 16:18:25 +0100 (CET)
Message-ID: <50FAB941.8020606@deployingradius.com>
Date: Sat, 19 Jan 2013 10:18:25 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Bernard Aboba 
References: <023601cdf5b2$fa462fe0$eed28fa0$@augustcellars.com>, , <50F9AEE8.9070105@deployingradius.com>, , <027601cdf5d5$7b8511d0$728f3570$@augustcellars.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: "radext@ietf.org" , Jim Schaad , "draft-ietf-radext-nai@tools.ietf.org" 
Subject: Re: [radext] Comments on draft-ietf-radext-nai-01
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: Sat, 19 Jan 2013 15:18:28 -0000

Bernard Aboba wrote:
> [BA] OK.  The question remains whether an NAI realm received from an
> 8-bit clean client (e.g. an EAP supplicant) will necessarily contains
> "IDNA-valid" labels.  The RADIUS Dynamic Discovery document says "no" --
> and AFAIK, no existing EAP implementations utilize NFC, so that is correct.

  The question now is: what do we want?  Do we want the NAI to have a
normal form?  Your previous messages indicated "yes".

> [BA] Assuming that the client converts the NAI to UTF-8 before sending
> it, does this problem really exist?  The NFC algorithm does not require
> knowledge of the locale, right?

  I believe so.

> [BA] The problem that the NAI realm output by the client may not be
> IDNA-valid, even if it is in UTF-8, and adding "MUST" to this document
> won't make it so.

  The current document says that NFC is RECOMMENDED.  It also says that

* Realms MUST be of the form that can be registered as a Fully Qualified
Domain Name (FQDN) within the DNS.

  Which also means it's an IDNA-valid label, containing U-labels in NFC.

  My $0.02 is that normalization should be done at the edges of the
network, where possible.  That means either the EAP supplicant, or the
system which feeds the identity into the EAP-supplicant.

  Doing it elsewhere is a nightmare.  Many authentication protocols
depend on cryptographic manipulation of the identity.  So AAA systems
would now have to track *two* identities.  The normalized form, and the
form as entered by the user.

  Alan DeKok.

From hartmans@painless-security.com  Sun Jan 20 10:39:15 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C38A21F84D3 for ; Sun, 20 Jan 2013 10:39:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.433
X-Spam-Level: 
X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, FRT_EXPERIENCE=2.333]
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 u1inXmcBXn83 for ; Sun, 20 Jan 2013 10:39:14 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D1A0521F84CE for ; Sun, 20 Jan 2013 10:39:14 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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 A316120180; Sun, 20 Jan 2013 13:35:41 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 24F3D43F7; Sun, 20 Jan 2013 13:39:07 -0500 (EST)
From: Sam Hartman 
To: Alan DeKok 
References: <023601cdf5b2$fa462fe0$eed28fa0$@augustcellars.com> <50F9AEE8.9070105@deployingradius.com>  <027601cdf5d5$7b8511d0$728f3570$@augustcellars.com>  <50FAB941.8020606@deployingradius.com>
Date: Sun, 20 Jan 2013 13:39:07 -0500
In-Reply-To: <50FAB941.8020606@deployingradius.com> (Alan DeKok's message of "Sat, 19 Jan 2013 10:18:25 -0500")
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: Bernard Aboba , "radext@ietf.org" , Jim Schaad , "draft-ietf-radext-nai@tools.ietf.org" 
Subject: Re: [radext] Comments on draft-ietf-radext-nai-01
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: Sun, 20 Jan 2013 18:39:15 -0000

>>>>> "Alan" == Alan DeKok  writes:

    Alan> Bernard Aboba wrote:
    >> [BA] OK.  The question remains whether an NAI realm received from
    >> an 8-bit clean client (e.g. an EAP supplicant) will necessarily
    >> contains "IDNA-valid" labels.  The RADIUS Dynamic Discovery
    >> document says "no" -- and AFAIK, no existing EAP implementations
    >> utilize NFC, so that is correct.

    Alan>   The question now is: what do we want?  Do we want the NAI to
    Alan> have a normal form?  Your previous messages indicated "yes".

We want people who are interpreting the NAI to do
normalization-insensitive and to the extent we can get it
input-method-insensitive operations on them.

One crue way to do that is to normalize the NAI. If you're going to look
something up in a database  that is just going to do an exact-match
search (DNS is a great example) then normalizing the NAI is the best you
can do.
DNS illustrates that the specific normalization/canonicalization is
often database specific.

However, if you have more control over the database, you probably just
want a normalization-insensitive search. Think of this is the 00's
version of case-insensitive comparison.

This tends to be an area where a lot of SHOULD language is appropriate
and no MUST language is appropriate.
Things like  the result SHOULD be the same regardless of what
normalization form the client submits.
Servers SHOULD perform comparisons that are insensitive to Unicode
normalization forms.

Also, note this is an area where advice will change over time and where
we'll get more requirements in the future.  Fortunately in what I've
said above the requirements are all on entities interpreting the NAI
(proxies making routing decisions; servers looking up users; etc), so
only one party needs to implement new requirements in order to provide
an enhanced e xperience.

The tricky bit comes in when hashes are involved.
Fortunately that seems rare with NAIs although not so rare
withmethod-specific  EAP
identities which may be related  to NAIs.
I think we can mostly avoid it in this document though.

--Sam

From ietf@augustcellars.com  Sun Jan 20 11:21:35 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C1C21F86DD for ; Sun, 20 Jan 2013 11:21:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.534
X-Spam-Level: 
X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 q0tLZxzjJZxH for ; Sun, 20 Jan 2013 11:21:34 -0800 (PST)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBD3D21F84F5 for ; Sun, 20 Jan 2013 11:21:20 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 44D8A2C9C5; Sun, 20 Jan 2013 11:21:20 -0800 (PST)
From: "Jim Schaad" 
To: "'Bernard Aboba'" , "'Alan DeKok'" 
References: <023601cdf5b2$fa462fe0$eed28fa0$@augustcellars.com>, , <50F9AEE8.9070105@deployingradius.com>, , <027601cdf5d5$7b8511d0$728f3570$@augustcellars.com> 
In-Reply-To: 
Date: Sun, 20 Jan 2013 11:20:58 -0800
Message-ID: <02c101cdf743$470100d0$d5030270$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C2_01CDF700.38DED240"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGeKr2aHOFwXSRqsQlSoUSKgYf7RQKjVYlxAdLczlgCFW4Q0AJ7JleKmGn5FXA=
Content-Language: en-us
Cc: radext@ietf.org, draft-ietf-radext-nai@tools.ietf.org
Subject: Re: [radext] Comments on draft-ietf-radext-nai-01
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: Sun, 20 Jan 2013 19:21:35 -0000

This is a multipart message in MIME format.

------=_NextPart_000_02C2_01CDF700.38DED240
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

[BA] OK.  The question remains whether an NAI realm received from an 8-bit
clean client (e.g. an EAP supplicant) will necessarily contains "IDNA-valid"
labels.  The RADIUS Dynamic Discovery document says "no" -- and AFAIK, no
existing EAP implementations utilize NFC, so that is correct. 

 

[JLS]  So I just went and read the RADIUS Dynamic Discover document.  I
don't know that it says that the NAI realm will or will not be "IDNA-valid"
.  However, I believe that it really says what you get here may or may not
be an NAI at all.  It allows for, among other things,  multiple '@'
characters to be placed in the user name.  However, in the long run, caveat
what it says about local consortium mangling of names, it does expect that
it is an IDNA-valid realm that it will be able to do a DNS query with.
Indeed in section 2.3.1 it says that if you can't do the mapping, then you
get an error condition for the lookup..

 


------=_NextPart_000_02C2_01CDF700.38DED240
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 [BA] OK.  The =
question remains whether an NAI realm received from an 8-bit clean =
client (e.g. an EAP supplicant) will necessarily contains =
"IDNA-valid" labels.  The RADIUS Dynamic Discovery =
document says "no" -- and AFAIK, no existing EAP =
implementations utilize NFC, so that is correct. =

 
[JLS]  So I just went and read the RADIUS Dynamic Discover =
document.  I don’t know that it says that the NAI realm will =
or will not be “IDNA-valid” .  However, I believe that =
it really says what you get here may or may not be an NAI at all.  =
It allows for, among other things,  multiple ‘@’ =
characters to be placed in the user name.  However, in the long =
run, caveat what it says about local consortium mangling of names, it =
does expect that it is an IDNA-valid realm that it will be able to do a =
DNS query with.   Indeed in section 2.3.1 it says that if you =
can’t do the mapping, then you get an error condition for the =
lookup..
 
=


------=_NextPart_000_02C2_01CDF700.38DED240--


From ietf@augustcellars.com  Sun Jan 20 16:04:53 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2592021F8653 for ; Sun, 20 Jan 2013 16:04:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[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 w8rofjhjrtwz for ; Sun, 20 Jan 2013 16:04:52 -0800 (PST)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 866CD21F8629 for ; Sun, 20 Jan 2013 16:04:49 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 05DEE2CA03; Sun, 20 Jan 2013 16:04:46 -0800 (PST)
From: "Jim Schaad" 
To: 
Date: Sun, 20 Jan 2013 16:04:21 -0800
Message-ID: <02d201cdf76a$e04625a0$a0d270e0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac33TYNQ+eeVR/6dScy32OtyZMeGFQ==
Content-Language: en-us
Cc: radext@ietf.org
Subject: [radext] Comments on draft-ietf-radext-dynamic-discovery-05
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, 21 Jan 2013 00:04:53 -0000

First let me say that I probably don't understand all of the circumstances
that this document is aimed at, so some of my comments may be way off base.

1.  In the Abstract - it says that "It can be used in conjunction with..."
>From what I have seen, it is only used in conjunction with one or the other,
it cannot be used without one of them being there.  Am I wrong?  If so then
suggest "It is used in conjunction with either RADIUS/TLS or RADIUS/DTLS."

2.  Please fill in some introduction - even if it is as bad as just copying
the abstract.  A problem statement about what you are trying to solve would
be even better.

3.  In section 2.1 - I am unclear what the correct behavior would be if I
have one user session open and I receive a new user Access-Request message.
Should I re-resolve or use the cached information?

4.  In section 2.2 - example b - you need to remove the quotes on the last
field of the example.

5.  In section 2.2. - I am lost on terminology -  Just after Figure 3 you
say "the label used for".  I am unclear in this context what you mean by
label.  This may be a deficiency of background for me.  However are we
talking about the realm in the user name, the  field in the SRV or NAPTR
records?

6. In section 2.3.1 - This is purely personal preference.  I find it hard to
locate the "variables" of the algorithm when they are a single character in
text.  This is especially true with I as it is visually close to a great
number of other characters.  I request they get widened in some fashion to
be more distinguishable.  If you choose to ignore this, I can easily live
with it.

7.  In section 2.3.1 - not explicitly stated but implied by the pattern is
that user cannot be the empty string.

8.  In section 2.3.1 - the list of possible errors include "Usage of
multiple @ separators", however this is covered in the first paragraph and a
deterministic algorithm is provided for dealing with it.

9. In section 2.3.2 - s/set of the tuple/set of tuples/  Current text can be
read as the set being the tuple not being a setup of the tuples.

10.  In section 2.3.3, step 4 - suggest s/O = { }/O= { empty set }/

11.  In section 2.3.3, step 4 - what is to be considered an error at this
point.  For example, there are a number of odd conditions that can be
returned from DNSSEC, specifically the "indeterminate" state.

12. In section 2.3.3, step 6 - suggest s/no result/no records found/

13.  In section 2.3.3, step 7 - text is unclear - is the set for all lookup
results or just for all hostnames in the final lookup result?  Also, should
secondary lookups do just NAPTR lookups or should they be doing SRV lookups
as well?

14.  In section 2.3.3, step 9 - text is unclear if I can do the lookup with
each of the prefixes or just with one.  As text is written I can only use
one prefix and can't do both.

15.  In section 2.3.3, step 13 - What subsequent lookup steps am I supposed
to be performing?   According to RFC 3958 section 5.1, SRV provides a single
layer of indirection; the outcome of an SRV lookup is a new domain name for
which the A RR is to be found.

16. In section 2.3.4 - Does the validity period of the TTL apply to a
currently open user validation session?  Do you close that or do you just
re-run the algorithm when a new ACCESS-REQUEST comes in for the realm?

17.  In section 2.3.4 - Given that the above algorithm does not return a TTL
value in the event of an empty set or define how to know the TTL value -
what is the TTL value to be used in in paragraph 2 "negative TTL"?

18.  In section 2.3.4 - This question is due to a lack of knowledge on my
part - Is there a specific error that should be returned at the RADIUS level
for the last two paragraphs in section 2.3.4 to indicate that I can't find
the path, but somebody else might be able to?

19.  In section 2.3.5 - Does it make sense to return a result, but to
continue the algorithm and store the result after the timeouts for later
use?

20.  I find the security considerations to be completely inadequate for this
document.  

Use of a certificate is only going to be valid if the original realm name
that is the input the validation routine is what is found and matched in the
certificate.  In this case I would not know where in the name or alt name
fields of the certificate it would be found.  You cannot validate to the
final DNS name as that is now an untrusted value.

The suggestion of out-of-band validation methods ignores the existence of
DANE

The NAI document suggests that the RADIUS peer is pre-configured with
information about certificates or TLS validation data.  The suggested text
works in the case that the table says do dynamic lookup and here is the TLS
configuration data.  But in other cases it is completely unclear how a
TLS-PSK would be found for a dynamic lookup.

21 - In the IANA consideration section - do you want to reserve the string
"_radiusdtls" as well as "_radiustls" as Service labels?




From alex@um.es  Thu Jan 24 01:53:05 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8AA21F847B; Thu, 24 Jan 2013 01:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Sfc2RJwjZSVp; Thu, 24 Jan 2013 01:53:04 -0800 (PST)
Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6D521F8476; Thu, 24 Jan 2013 01:53:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 0A326536FD; Thu, 24 Jan 2013 10:53:03 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon11.um.es
Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0PrYkMoGtvtm; Thu, 24 Jan 2013 10:53:02 +0100 (CET)
Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id 2D56C536FB; Thu, 24 Jan 2013 10:53:01 +0100 (CET)
Message-ID: <5101047D.20103@um.es>
Date: Thu, 24 Jan 2013 10:53:01 +0100
From: Alejandro Perez Mendez 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: "radext@ietf.org" 
References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com>
In-Reply-To: <20130124094903.28508.37132.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130124094903.28508.37132.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------000103030703090803090109"
Cc: "abfab@ietf.org" 
Subject: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 24 Jan 2013 09:53:05 -0000

This is a multi-part message in MIME format.
--------------000103030703090803090109
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

we have uploaded a new version of our RADIUS fragmentation draft. This 
version introduces some relevant changes:

  * Improved description of fragmentation of Access-Accept packets.
  * Use of Additional-Authorization service type instead of Authorize-Only
  * Improved description of CHUNK size calculation.
  * New section describing how to deal with Proxy-State attributes,
    including the mechanism used by the RADIUS client to discover the
    amount of space required for them along the path (also includes the
    description of a new RADIUS Attribute for that purpose).
  * Improved description of the management of State attributes.
  * New section about the interaction with RADIUS-EAP.
  * New section describing in detail how to rebuild a received
    fragmented packet.

Regards,
Alejandro


-------- Mensaje original --------
Asunto: 	New Version Notification for 
draft-perez-radext-radius-fragmentation-04.txt
Fecha: 	Thu, 24 Jan 2013 01:49:03 -0800
De: 	internet-drafts@ietf.org
Para: 	alex@um.es
CC: 	aland@networkradius.com, gabilm@um.es, diego@tid.es, 
pereniguez@um.es, rafa@um.es



A new version of I-D, draft-perez-radext-radius-fragmentation-04.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 04
Title:		 Support of fragmentation of RADIUS packets
Creation date:	 2013-01-24
WG ID:		 Individual Submission
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-04.txt
Status:          http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation
Htmlized:        http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-04

Abstract:
    This document describes a mechanism providing fragmentation support
    of RADIUS packets that exceed the 4 KB limit.

                                                                                   


The IETF Secretariat




--------------000103030703090803090109
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Hello,

    

    we have uploaded a new version of our RADIUS fragmentation draft.
    This version introduces some relevant changes:

    
    
      
  • Improved description of fragmentation of Access-Accept
        packets.
    • 
      
  • Use of Additional-Authorization service type instead of
        Authorize-Only
    • 
      
  • Improved description of CHUNK size calculation.
    • 
      
  • New section describing how to deal with Proxy-State
        attributes, including the mechanism used by the RADIUS client to
        discover the amount of space required for them along the path
        (also includes the description of a new RADIUS Attribute for
        that purpose).
    
      
    • 
      
  • Improved description of the management of State attributes.
    • 
      
  • New section about the interaction with RADIUS-EAP.
    • 
      
  • New section describing in detail how to rebuild a received
        fragmented packet.
    • 
    

    Regards,

    Alejandro

    

    


      -------- Mensaje original --------
      

        
          

            Asunto:
            
            New Version Notification for
              draft-perez-radext-radius-fragmentation-04.txt
          

          

            Fecha: 
            Thu, 24 Jan 2013 01:49:03 -0800
          

          

            De: 
            internet-drafts@ietf.org
          

          

            Para: 
            alex@um.es
          

          

            CC: 
            aland@networkradius.com, gabilm@um.es, diego@tid.es,
              pereniguez@um.es, rafa@um.es
          

        
      

      

      

      
A new version of I-D, draft-perez-radext-radius-fragmentation-04.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 04
Title:		 Support of fragmentation of RADIUS packets
Creation date:	 2013-01-24
WG ID:		 Individual Submission
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-04.txt
Status:          http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation
Htmlized:        http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-04

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS packets that exceed the 4 KB limit.

                                                                                  


The IETF Secretariat



      

    

    

  


--------------000103030703090803090109--

From bernard_aboba@hotmail.com  Thu Jan 24 06:40:02 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B1F21F8A25 for ; Thu, 24 Jan 2013 06:40:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.652
X-Spam-Level: 
X-Spam-Status: No, score=-101.652 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 kV5l95+XIYpG for ; Thu, 24 Jan 2013 06:40:02 -0800 (PST)
Received: from blu0-omc2-s28.blu0.hotmail.com (blu0-omc2-s28.blu0.hotmail.com [65.55.111.103]) by ietfa.amsl.com (Postfix) with ESMTP id CDFF221F8A06 for ; Thu, 24 Jan 2013 06:39:58 -0800 (PST)
Received: from BLU405-EAS36 ([65.55.111.73]) by blu0-omc2-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 24 Jan 2013 06:39:58 -0800
X-EIP: [on0v4YbJVhk9+H0R8PZFXXHAPh7P43Wt]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References: 
From: Bernard Aboba 
MIME-Version: 1.0 (1.0)
In-Reply-To: 
Date: Thu, 24 Jan 2013 06:39:57 -0800
To: siva kumar 
X-OriginalArrivalTime: 24 Jan 2013 14:39:58.0389 (UTC) FILETIME=[AEF70E50:01CDFA40]
Cc: radext@ietf.org
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 14:40:02 -0000

On Jan 24, 2013, at 1:48 AM, "siva kumar"  wrote:

> Hi Bernard/Calhoun,
>=20
> Currently in our system, we are discarding packets with certain AVP in Acc=
ess challenge packets. For eg: If framed-Ip-address is present in the
> Access challenge packet, we are dropping it. I read through the RFC and it=
 is not specified what are the AVPs that are valid for Access challenge=20
> packets. It will be great if you could throw some light for me.=20
>=20
> In our system only 10 AVPs are allowed in the Access challenge packet. Is i=
t right to discard Access challenge packets based on the AVP sent by the ser=
ver.
>=20
> Awaiting your response regarding this.
>=20
> Thanks & Regards,
> Sivakumar.S

From dnelson@elbrys.com  Thu Jan 24 07:18:29 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACFE21F8A2F for ; Thu, 24 Jan 2013 07:18:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 qUbG-SUUPo11 for ; Thu, 24 Jan 2013 07:18:28 -0800 (PST)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 99C1721F8A2A for ; Thu, 24 Jan 2013 07:18:28 -0800 (PST)
Received: by mail-we0-f169.google.com with SMTP id t11so2880399wey.0 for ; Thu, 24 Jan 2013 07:18:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=/p92xbUlrVpub9SgVy6s0j7tEM+fJeS06EHPFBY2qVU=; b=CXqYAqqlZQ7+IDPBP1EXe5kv438TSjke9S/i1iYrQxWle1Ltl3XGKaBZOU6xZgPNfZ 5J6j6UCYfuBItgzQNthnGeZvP3CajLiqF5iql7pYTuHR8wh009LXppM52wQyH0XofhdE Ek/b7aujplCSpoiJRU0wGC32WSBTnx5hhHE2UoZNRxdngWJZMz/2FSy1iQl2uiqLiWFZ GehjzLdMhddqVsLqs7VTOELXpD5cw1/zqJCAb2szTdGrJprOHLCcXkxTkDpnEwItVFy/ 8xQHcTPU7xA8xBp1givTanbpQ96FPn5Wg/FR0y71Y9j/iASuNYSq4AErgJuRIE6MiRFO JN3w==
MIME-Version: 1.0
X-Received: by 10.180.101.99 with SMTP id ff3mr3698301wib.21.1359040706671; Thu, 24 Jan 2013 07:18:26 -0800 (PST)
Received: by 10.194.124.107 with HTTP; Thu, 24 Jan 2013 07:18:26 -0800 (PST)
In-Reply-To: 
References:  
Date: Thu, 24 Jan 2013 10:18:26 -0500
Message-ID: 
From: Dave Nelson 
To: siva kumar 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmuq02vMRkoEy3/AdZ5zI+i2hWJ/n0q9ay0lMtOxHu2ffgkg82HaMqIAHjJC6VrgLDiOS76
Cc: Bernard Aboba , radext@ietf.org
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 15:18:29 -0000

>> Currently in our system, we are discarding packets with certain
>> AVP in Access challenge packets. For eg: If framed-Ip-address
>> is present in the Access challenge packet, we are dropping it.
>> I read through the RFC and it is not specified what are the AVPs
>> that are valid for Access challenge packets.

Ummm... Doesn't this section tell you exactly that?

3.3.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in packets including EAP-Message attribute(s), and in what quantity.
   The EAP-Message and Message-Authenticator attributes specified in
   this document MUST NOT be present in an Accounting-Request.  If a
   table entry is omitted, the values found in [RFC2548], [RFC2865],
   [RFC2868], [RFC2869] and [RFC3162] should be assumed.

Request  Accept  Reject  Challenge   #    Attribute
0-1      0-1     0       0            1   User-Name
0        0       0       0            2   User-Password [Note 1]
0        0       0       0            3   CHAP-Password [Note 1]
0        0       0       0           18   Reply-Message
0        0       0       0           60   CHAP-Challenge
0        0       0       0           70   ARAP-Password [Note 1]
0        0       0       0           75   Password-Retry
1+       1+      1+      1+          79   EAP-Message [Note 1]
1        1       1       1           80   Message-Authenticator [Note 1]
0-1      0       0       0           94   Originating-Line-Info [Note 3]
0        0       0-1     0-1        101   Error-Cause [Note 2]
Request  Accept  Reject  Challenge   #    Attribute

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

From hartmans@painless-security.com  Thu Jan 24 07:40:30 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA2321F87A3; Thu, 24 Jan 2013 07:40:30 -0800 (PST)
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 OsE-coaB8nI3; Thu, 24 Jan 2013 07:40:29 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9B51B21F873D; Thu, 24 Jan 2013 07:40:29 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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 D1AA92026F; Thu, 24 Jan 2013 10:36:47 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2B30B43FD; Thu, 24 Jan 2013 10:40:27 -0500 (EST)
From: Sam Hartman 
To: Alejandro Perez Mendez 
References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es>
Date: Thu, 24 Jan 2013 10:40:27 -0500
In-Reply-To: <5101047D.20103@um.es> (Alejandro Perez Mendez's message of "Thu,  24 Jan 2013 10:53:01 +0100")
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" 
Subject: Re: [radext] [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 24 Jan 2013 15:40:30 -0000

This sounds great.
What's the state within radext?
I know it's now chartered; how can we help get this adopted?

From aland@deployingradius.com  Thu Jan 24 07:46:09 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A8C21F87B2 for ; Thu, 24 Jan 2013 07:46:09 -0800 (PST)
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 Do55tgFb3wew for ; Thu, 24 Jan 2013 07:46:08 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D56721F8584 for ; Thu, 24 Jan 2013 07:46:08 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id EB4232241106; Thu, 24 Jan 2013 16:46:06 +0100 (CET)
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 kH-YZIQvD4mA; Thu, 24 Jan 2013 16:46:03 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id B54352241069; Thu, 24 Jan 2013 16:46:02 +0100 (CET)
Message-ID: <5101573B.8080409@deployingradius.com>
Date: Thu, 24 Jan 2013 10:46:03 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Dave Nelson 
References: 	 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: siva kumar , Bernard Aboba , radext@ietf.org
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 15:46:09 -0000

Dave Nelson wrote:
>>> Currently in our system, we are discarding packets with certain
>>> AVP in Access challenge packets. For eg: If framed-Ip-address
>>> is present in the Access challenge packet, we are dropping it.
>>> I read through the RFC and it is not specified what are the AVPs
>>> that are valid for Access challenge packets.
> 
> Ummm... Doesn't this section tell you exactly that?

  True.

  I'm a bit surprised, though, at the idea that packets can be discarded
like that.  The RFCs make it clear when packets should be silently
discarded.  They *don't* say that packets should be silently discarded
when they contain unexpected data.

  We know that the standard space contains unallocated attributes.  What
happens when an implementation receives a packet containing one of those
attributes?

  The "Table of Attributes" *implies* that it is authoritative.  So any
attribute *not* in the list is presumed to be not allowed.  Therefore,
by the above logic, that packet should be discarded.

  So any deployed implementation would know about *only* the attributes
allocated when it was published.  And would discard packets from all
newer standards.

  This practice means that it will be impossible to publish new standards.

  So this practice of discarding packets should be STRONGLY DISCOURAGED.
 Instead, the "Table of Attributes" should be used to filter attributes
in the packet.

  When the "Table of Attributes" contains a "0", and the attribute is
received in a packet, then that attribute should be discarded.  And only
that attribute should be discarded.  All other attributes should be left
alone.  The packet should be processed as normal.

  Discarding well-formed packets from valid clients is an absolutely
horrible practice.  It will break pretty much everything in RADIUS
deployments.  I cannot emphasize enough just how bad an idea this is.

  Alan DeKok.

From aland@deployingradius.com  Thu Jan 24 07:51:40 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6966321F88EE; Thu, 24 Jan 2013 07:51:38 -0800 (PST)
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 bXhala9WstEY; Thu, 24 Jan 2013 07:51:36 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3989C21F8868; Thu, 24 Jan 2013 07:51:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id B3C402241106; Thu, 24 Jan 2013 16:50:49 +0100 (CET)
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 n9gsYu7VFzJD; Thu, 24 Jan 2013 16:50:48 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 6DB752241069; Thu, 24 Jan 2013 16:50:48 +0100 (CET)
Message-ID: <51015859.4010008@deployingradius.com>
Date: Thu, 24 Jan 2013 10:50:49 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Sam Hartman 
References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com>	<5101047D.20103@um.es> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez 
Subject: Re: [radext] [abfab] Fwd: New Version Notification for	draft-perez-radext-radius-fragmentation-04.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, 24 Jan 2013 15:51:40 -0000

Sam Hartman wrote:
> This sounds great.
> What's the state within radext?
> I know it's now chartered; how can we help get this adopted?

  Pipe up in radext.  It's on the RADEXT charter now.  So we'll need
reviewers, and a call for WG adoption.

  Alan DeKok.

From dnelson@elbrys.com  Thu Jan 24 07:58:03 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A75521F867B for ; Thu, 24 Jan 2013 07:58:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 1yqe05InC3CJ for ; Thu, 24 Jan 2013 07:58:03 -0800 (PST)
Received: from mail-we0-x22b.google.com (we-in-x022b.1e100.net [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BCD0021F8652 for ; Thu, 24 Jan 2013 07:58:02 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id u3so3103861wey.30 for ; Thu, 24 Jan 2013 07:58:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=N/QQ0hYLMXjPt6hhvab41LxXI/QQyFye0iTR3FUuyiM=; b=n8381JHkMTP8mowAqQK+MHhW7XcP9FRttEc0VTWpF3Cdyqh0uH+2WMUigv4IP/yopw UHUMSdIa805MRv/zBd2X/2QY1JOuds25rOV8izeKJ/yePa67QkQr59f+Hko9en8BT3pQ fm7qnlK5QsVA4FaNN4K+z1aMjwASYGQKnQ0hy+cL+OLVHDbhzN2cuQJUyuDcS4CY43Kp eQf/i36ac8J4lvrdzhvHYT2Bl+glccz3CpUgaxKZjni8ILKt0+WOizyaeoGfUkoxXBdW pnhWCNVRASOqwL1rmwCu6F9tK4a7mcIbhFK3Z1nyprOJ/iqclN3W+/mk1DjQbagxHonv wA+A==
MIME-Version: 1.0
X-Received: by 10.180.77.68 with SMTP id q4mr3956589wiw.10.1359043081741; Thu, 24 Jan 2013 07:58:01 -0800 (PST)
Received: by 10.194.124.107 with HTTP; Thu, 24 Jan 2013 07:58:01 -0800 (PST)
In-Reply-To: <5101573B.8080409@deployingradius.com>
References:    <5101573B.8080409@deployingradius.com>
Date: Thu, 24 Jan 2013 10:58:01 -0500
Message-ID: 
From: Dave Nelson 
To: Alan DeKok 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlQlFiItEaQsn1+sU5bk8uKyIaRDCU5xlJNlnNKVVbujaFAo0RmIlb9qqQGKCsVUbmc078j
Cc: siva kumar , Bernard Aboba , radext@ietf.org
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 15:58:03 -0000

On Thu, Jan 24, 2013 at 10:46 AM, Alan DeKok  wrote:

>   Discarding well-formed packets from valid clients is an absolutely
> horrible practice.  It will break pretty much everything in RADIUS
> deployments.  I cannot emphasize enough just how bad an idea this is.

I think that's generally true.  I'm not sure it's universally true.
If we're talking about a specific kind of RADIUS packet flows, for
example the interactive exchange of EAP-Messages, it becomes unclear
how the semantics of RADIUS Atributes that provision service are to be
applied.  I'm not sure that starting just any kind of service from the
NAS ought to be allowed in the middle of an authentication exchange.
I think there is an fundamental assumption that RADIUS provisions
service delivery at the NAS only *after* a successful authentication.
Therefore, properly applying service provisioning attributes in the
middle of an EAP exchange seems to be an undefined, or at least
undesirable, operation.

No?

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

From aland@deployingradius.com  Thu Jan 24 08:23:45 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA2921F89CB for ; Thu, 24 Jan 2013 08:23:45 -0800 (PST)
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 1s1N4S17eDfV for ; Thu, 24 Jan 2013 08:23:44 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4BC21F895F for ; Thu, 24 Jan 2013 08:23:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 30E9E2241106; Thu, 24 Jan 2013 17:23:43 +0100 (CET)
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 VF0eGo4jTEDO; Thu, 24 Jan 2013 17:23:42 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id E346E2241069; Thu, 24 Jan 2013 17:23:41 +0100 (CET)
Message-ID: <5101600C.7020906@deployingradius.com>
Date: Thu, 24 Jan 2013 11:23:40 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Dave Nelson 
References: 			<5101573B.8080409@deployingradius.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: siva kumar , Bernard Aboba , radext@ietf.org
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 16:23:45 -0000

Dave Nelson wrote:
> On Thu, Jan 24, 2013 at 10:46 AM, Alan DeKok  wrote:
> 
>>   Discarding well-formed packets from valid clients is an absolutely
>> horrible practice.  It will break pretty much everything in RADIUS
>> deployments.  I cannot emphasize enough just how bad an idea this is.
> 
> I think that's generally true.  I'm not sure it's universally true.
> If we're talking about a specific kind of RADIUS packet flows, for
> example the interactive exchange of EAP-Messages, it becomes unclear
> how the semantics of RADIUS Atributes that provision service are to be
> applied.

  Service provisioning is done after the Access-Accept.  Any service
provisioning in an Access-Challenge should be ignored.

>  I'm not sure that starting just any kind of service from the
> NAS ought to be allowed in the middle of an authentication exchange.
> I think there is an fundamental assumption that RADIUS provisions
> service delivery at the NAS only *after* a successful authentication.
> Therefore, properly applying service provisioning attributes in the
> middle of an EAP exchange seems to be an undefined, or at least
> undesirable, operation.

  Yes.  Absolutely.

  But discarding the Access-Challenge entirely?  What that means is I
can *destroy* a RADIUS roaming infrastructure by included
Framed-IP-Address in an Access-Challenge.  I can do this as the home
server, or as an intermediate proxy.  Any visited RADIUS server will
panic and discard the packet.

  And... no one will be able to authenticate.

  Discarding well-formed packets because they contain *too much*
information violates the robustness principle of RFC 1122, Section
1.2.2, which was published in 1989.

  We've known for ~23 years that being liberal with "unexpected" data is
a good idea.  Let's not change that now.

  Alan DeKok.

From dnelson@elbrys.com  Thu Jan 24 09:09:21 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C27B21F89A3 for ; Thu, 24 Jan 2013 09:09:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level: 
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.499,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Lpjj06oBclx4 for ; Thu, 24 Jan 2013 09:09:20 -0800 (PST)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5C59621F8884 for ; Thu, 24 Jan 2013 09:09:20 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id hm6so649828wib.15 for ; Thu, 24 Jan 2013 09:09:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=GREjNdDw/uYeqO4SYwnmujPU76BssM3B6DqzY7M6Kp0=; b=ewwLpLjQ6+S4cB3oQL1aOf2ZdJaVwL8Wqw5T3+57P0sBTD+fOdBZriHtOGHkBW/ArU JC2ancB/MKpAs8EthzgK4F0v6OSNNk9eQpPzJhEIZlIJQPORtphsaQxnlzd1mkrIeLrp k0kiY0tT4QM+y+tF2E5yCxqW5Dl5AHwQvRJ1JTGI062Z7H742aMb4xHj9rhxN982b98o Sfz9VWa6h8rMV9q/Q3FAbWaSIQhXQxY4ud2QaNKaMydMrlau5d+YJUk+ljUYAT6JMQOF a1+HdfFyuc8Vols7z3i1x+wZH59QaY0Nb7wovnwj1uTuSA4rXn9fBm/BlDcvi+66gwr7 hzvg==
MIME-Version: 1.0
X-Received: by 10.194.76.204 with SMTP id m12mr4321010wjw.21.1359047359572; Thu, 24 Jan 2013 09:09:19 -0800 (PST)
Received: by 10.194.124.107 with HTTP; Thu, 24 Jan 2013 09:09:19 -0800 (PST)
In-Reply-To: <5101600C.7020906@deployingradius.com>
References:    <5101573B.8080409@deployingradius.com>  <5101600C.7020906@deployingradius.com>
Date: Thu, 24 Jan 2013 12:09:19 -0500
Message-ID: 
From: Dave Nelson 
To: Alan DeKok 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQk7AR7DnJZjBRIh6WYi+96rf7WgcK++XsglnK8n6A966Pvq+YxjJCh4elOZQZiNsk8xYoDN
Cc: siva kumar , Bernard Aboba , radext@ietf.org
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 17:09:21 -0000

On Thu, Jan 24, 2013 at 11:23 AM, Alan DeKok  wrote:

>   But discarding the Access-Challenge entirely?

No, I agree that's problematic.  OTOH, the notion of attribute
filtering might violate the notion that some attributes are implicitly
considered "mandatory".  I don't see a simple, zero-impact
recommendation to cover the OP's question for all cases.  The best I
see is the attribute filtering suggestion, in the context of
Access-Challenge, with the caveat that any service provisioning
attributes SHOULD (MUST ?) be discarded.  Other attributes will have
to be considered on the specific use case ans their particular
semantics.

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

From dnelson@elbrys.com  Thu Jan 24 09:49:18 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F29E21F8951 for ; Thu, 24 Jan 2013 09:49:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.644
X-Spam-Level: 
X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.333,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 GNASff4+QxBy for ; Thu, 24 Jan 2013 09:49:17 -0800 (PST)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 882BA21F885C for ; Thu, 24 Jan 2013 09:49:17 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id hm6so690375wib.9 for ; Thu, 24 Jan 2013 09:49:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=qHUSz51PZhz37hHMzwbzdcFxfNSGYaOduFZhYfxt6zU=; b=KcsCeVTF5pv96+dOcacTmN9xeStFKh9TJlq65QtfuBkeqjxNCwjKkDTe1zFmUzYMgg mbA59nWIp7K0omxdx9tWW/35DoSvtql+5AMiNg65DcMLJwHRIVVGS8DX8ddpdjmLmWEp j/vyzribHj5NxirNo3gVt8GjMV9ITyyJJRt/tZDKHQywnwme8PHXEONm5c+wabZMBjfY 5k82Z+Zj9xba0YZ5+wcAB34WxHrNXfNpO9dnVO0yA9RrmqZgI3ZtzIW886GlFrUFgXsp 7Mj7NIA563tooiTlVSVovCIwfOFH+juzXg0fpVcmxJNNE1T6GmdzwtOOq80nJHqSfHjB 6ORw==
MIME-Version: 1.0
X-Received: by 10.194.76.204 with SMTP id m12mr4539715wjw.21.1359049756718; Thu, 24 Jan 2013 09:49:16 -0800 (PST)
Received: by 10.194.124.107 with HTTP; Thu, 24 Jan 2013 09:49:16 -0800 (PST)
In-Reply-To: <5101600C.7020906@deployingradius.com>
References:    <5101573B.8080409@deployingradius.com>  <5101600C.7020906@deployingradius.com>
Date: Thu, 24 Jan 2013 12:49:16 -0500
Message-ID: 
From: Dave Nelson 
To: Alan DeKok 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQl5+eqIQGLyshF3QmhqUr6cc1hPBQAI88TwjGkFqq08/8B4rZivSgf2yO6SUDFmZjTrHY8e
Cc: siva kumar , Bernard Aboba , radext@ietf.org
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 17:49:18 -0000

On Thu, Jan 24, 2013 at 11:23 AM, Alan DeKok  wrote:

>   Discarding well-formed packets because they contain *too much*
> information violates the robustness principle of RFC 1122, Section
> 1.2.2, which was published in 1989.

Yes, but...

I think we need to also honor the principle of "least surprise".
Selectively honoring or ignoring attributes on an implementor choice
basis doesn't honor that principle.  What the NAS (or Proxy Server)
might think to be "too much" or extraneous information might have been
important to the home server.  It's a matter of policy and intent.
There are some attributes in RADIUS that have implicit "mandatory"
status, in which case the inability of the NAS to support or enforce
them requires the NAS to deny service.

I guess this comes down to the difference between syntactically
well-formed packets and semantically well-formed packets.

I suspect that it's probably OK to filter out all attributes in an
Access-Challenge packet not permitted by the Table of Atributes in RFC
3579, for the use case of authentication by means of EAP.  By OK, I
mean *highly* RECOMMENDED.  We should explicitly address someplace
that's the right thing to do, in this use case, for those attributes
which are considered "mandatory".

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

From aland@deployingradius.com  Thu Jan 24 10:42:05 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAA411E8097 for ; Thu, 24 Jan 2013 10:42:05 -0800 (PST)
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 Y9wy+876wkBz for ; Thu, 24 Jan 2013 10:42:04 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 303BE21F8652 for ; Thu, 24 Jan 2013 10:42:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id CF1302241106; Thu, 24 Jan 2013 19:41:11 +0100 (CET)
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 0Ghh01hZz3rc; Thu, 24 Jan 2013 19:41:11 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 705412241069; Thu, 24 Jan 2013 19:41:10 +0100 (CET)
Message-ID: <51018045.8010605@deployingradius.com>
Date: Thu, 24 Jan 2013 13:41:09 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Dave Nelson 
References: 			<5101573B.8080409@deployingradius.com>		<5101600C.7020906@deployingradius.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: siva kumar , Bernard Aboba , radext@ietf.org
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 18:42:05 -0000

Dave Nelson wrote:
> I think we need to also honor the principle of "least surprise".
> Selectively honoring or ignoring attributes on an implementor choice
> basis doesn't honor that principle.

  That's not what I proposed.  The Table of Attributes is clear.
Framed-IP-Address doesn't belong in Access-Challenge.  If it exists, it
should be *treated* is if it occurred with multiplicity "0", as per the
table.

>  What the NAS (or Proxy Server)
> might think to be "too much" or extraneous information might have been
> important to the home server.  It's a matter of policy and intent.

  Exactly.  The extensions document talks about "invalid attribute" in
that context.  It says that unexpected information should be passed
as-is, as someone else might understand it.  It also says that the data
should be ignored if you don't understand it.

> There are some attributes in RADIUS that have implicit "mandatory"
> status, in which case the inability of the NAS to support or enforce
> them requires the NAS to deny service.

  Yes.  RFC 2865 Section 5.6 says unknown Service-Types MUST be treated
as Access-Reject.

  I can't find anything which says that provisioning *other* kinds of
unknown services should be treated as reject.  The text assumes that
Service-Type is always in the Access-Accept, even though the Table of
Attributes says it can be omitted.

  Perhaps that should also be clarified.  If a NAS doesn't find anything
it recognizes as provisioning a service, it MUST be treated as an
Access-Reject.

> I guess this comes down to the difference between syntactically
> well-formed packets and semantically well-formed packets.

  Yes.

> I suspect that it's probably OK to filter out all attributes in an
> Access-Challenge packet not permitted by the Table of Atributes in RFC
> 3579, for the use case of authentication by means of EAP.  By OK, I
> mean *highly* RECOMMENDED.  We should explicitly address someplace
> that's the right thing to do, in this use case, for those attributes
> which are considered "mandatory".

  Well, the extensions document is ongoing.  It may be a bit late to do
this (IETF last call).  But it already has text around "invalid
attributes".  And that text is relevant to this topic.

  If the WG agrees, I can update the extensions document with some text
around this subject.

  Alan DeKok.

From hartmans@painless-security.com  Thu Jan 24 10:49:40 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3F121F86BA for ; Thu, 24 Jan 2013 10:49:40 -0800 (PST)
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 L8G8+izYq6Zl for ; Thu, 24 Jan 2013 10:49:40 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD1F21F8691 for ; Thu, 24 Jan 2013 10:49:40 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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 A11F92026F; Thu, 24 Jan 2013 13:45:58 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1039743FD; Thu, 24 Jan 2013 13:49:38 -0500 (EST)
From: Sam Hartman 
To: Alan DeKok 
References:    <5101573B.8080409@deployingradius.com>  <5101600C.7020906@deployingradius.com>  <51018045.8010605@deployingradius.com>
Date: Thu, 24 Jan 2013 13:49:38 -0500
In-Reply-To: <51018045.8010605@deployingradius.com> (Alan DeKok's message of "Thu, 24 Jan 2013 13:41:09 -0500")
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: siva kumar , Bernard Aboba , Dave Nelson , radext@ietf.org
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 18:49:40 -0000

>>>>> "Alan" == Alan DeKok  writes:


I strongly agree with Alan here.
I think a NAS should treat such an unexpected attribute as if it had not
been present in the packet.
I'd prefer proxies pass along unfiltered because it makes it easier to
deploy extensions.
I'm OK with proxies permitting filtering, and I guess even OK with
default filters in proxies that support configuration. 

I would consider it incredibly bad from an extensibility standpoint if
someone started marketing a proxy that only permitted the attributes
listed in RFC 3579 for access-challenges containing EAP-Message and
didn't permit the behavior to be modified.

--Sam

From dnelson@elbrys.com  Thu Jan 24 10:53:22 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D3111E809A for ; Thu, 24 Jan 2013 10:53:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 iCOkTZvZa-Jo for ; Thu, 24 Jan 2013 10:53:21 -0800 (PST)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2A96511E80A4 for ; Thu, 24 Jan 2013 10:53:20 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id r5so941747wey.32 for ; Thu, 24 Jan 2013 10:53:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=d7NgN5LiiHAGF9pGSM1VYmp/j8WL8WZnO7Mnt75byvY=; b=ODWjING0NUI/hSAlJpBpAq6A+22J5gnFGbhrdK04I/9eprZRbcmmWIVSzFSFPh+bNJ +aR7SBddl9Y5SZRtGDUvJ//eFCAt0VemuPBq1FnGQdyylxLA+F5aiYMcM43eq29mh+W7 5NlnEcf4ikEBhyA0RB5cEyjphUlD/5MEGg/3kJT+q5xr9htiLri48bGVh5ag8O27Rty0 /ypEtsOj2ekDshAE+Sah7zSa8M+Z5pRst3EVLhbSna+gkcfnD0kcF0eeoa7CJ5Gb8C+G SxR/+fSAwy/zlrxvUG1+zZxGrP145nAM4tYkztj8vdUxTe2PSylTJGdIJj/H/Hj1Ztwu AneQ==
MIME-Version: 1.0
X-Received: by 10.180.86.39 with SMTP id m7mr5051797wiz.1.1359053600138; Thu, 24 Jan 2013 10:53:20 -0800 (PST)
Received: by 10.194.124.107 with HTTP; Thu, 24 Jan 2013 10:53:20 -0800 (PST)
In-Reply-To: <51018045.8010605@deployingradius.com>
References:    <5101573B.8080409@deployingradius.com>  <5101600C.7020906@deployingradius.com>  <51018045.8010605@deployingradius.com>
Date: Thu, 24 Jan 2013 13:53:20 -0500
Message-ID: 
From: Dave Nelson 
To: Alan DeKok 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQm9Oir7MABD2SwQ2XzYC2Bfhg3xs8oEYWXqkPZFV5LKDdARt50zfRD2MDvSwAbVVaOdVJkX
Cc: siva kumar , Bernard Aboba , radext@ietf.org
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 18:53:22 -0000

On Thu, Jan 24, 2013 at 1:41 PM, Alan DeKok  wrote:

>  I can't find anything which says that provisioning *other* kinds of
> unknown services should be treated as reject.

Section 2.5 of RFC 5080 says, in relevant part:

   In general, it is best for a RADIUS client to err on the side of
   caution.  On receiving an Access-Accept including an attribute of
   known Type for an unimplemented service, a RADIUS client MUST treat
   it as an Access-Reject, as directed in [RFC2865] Section 1.1.  On
   receiving an Access-Accept including an attribute of unknown Type, a
   RADIUS client SHOULD assume that it is a potential service
   definition, and treat it as an Access-Reject.  Unknown VSAs SHOULD be
   ignored by RADIUS clients.

   In order to avoid introducing changes in default behavior, existing
   implementations that do not obey this recommendation should make the
   behavior configurable, with the legacy behavior being enabled by
   default.  A configuration flag such as "treat unknown attributes as
   reject" can be exposed to the system administrator.  If the flag is
   set to true, then Access-Accepts containing unknown attributes are
   treated as Access-Rejects.  If the flag is set to false, then unknown
   attributes in Access-Accepts are silently ignored.

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

From dnelson@elbrys.com  Thu Jan 24 10:58:02 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2C321F84F2 for ; Thu, 24 Jan 2013 10:58:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 P2fRjZgAz1Se for ; Thu, 24 Jan 2013 10:58:02 -0800 (PST)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C9DAE21F84F0 for ; Thu, 24 Jan 2013 10:58:01 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id u3so3192645wey.30 for ; Thu, 24 Jan 2013 10:58:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=HLts92/tyqSGacvcjIv9h4C+vxBc0gOwwDcKT7cOrr0=; b=MxlmMsHWa36tcDjEYeqERKAe4U6/Xo77tMTyjFkxsqPJzLSGvhKx1YWYVaAWmCD/p3 nbQQWZ101/7O1hsrosDA4OctQxtIoBSDtRDkRBxpVwjqOqGmj4TdnHnSk6zYQLXm9atG mj5dKRoZONkywipHcJMJCNeAXjhPnUVOcVmaf78mRieWo38TI0cuwR0F7BMy5jp9WIzx 2r+Ph6Y5eB9b64/4w2n7fK0/8s8ntWI7O3aTlHYu5sREL/NXWnZ1sLldWCqd4jHwaqkB xUgbpq108j+TCtJTLOZExOcpie0+pIGFtClqIWPQxqXuBjihuJ5GtAm8Bg3Ls0YoKINK gaVw==
MIME-Version: 1.0
X-Received: by 10.180.75.135 with SMTP id c7mr5083563wiw.10.1359053880981; Thu, 24 Jan 2013 10:58:00 -0800 (PST)
Received: by 10.194.124.107 with HTTP; Thu, 24 Jan 2013 10:58:00 -0800 (PST)
In-Reply-To: 
References:    <5101573B.8080409@deployingradius.com>  <5101600C.7020906@deployingradius.com>  <51018045.8010605@deployingradius.com> 
Date: Thu, 24 Jan 2013 13:58:00 -0500
Message-ID: 
From: Dave Nelson 
To: Sam Hartman 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkckkrovgphWpPtQHuB5+9GTlfugWywPa/UUCjl3BQJ2AAyn5TAJuSuCGvnlSSJhdJcv0kV
Cc: siva kumar , Bernard Aboba , radext@ietf.org, Alan DeKok 
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 18:58:02 -0000

On Thu, Jan 24, 2013 at 1:49 PM, Sam Hartman
 wrote:

> I think a NAS should treat such an unexpected attribute as if it had not
> been present in the packet.

That might be OK for Access-Challenge packets.  RFC 5080 Section 2.5
says this is a really bad idea for Access-Accept packets.

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

From hartmans@painless-security.com  Thu Jan 24 11:00:11 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D3221F8566 for ; Thu, 24 Jan 2013 11:00:11 -0800 (PST)
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 22QKvHNjxUCm for ; Thu, 24 Jan 2013 11:00:10 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 77A7C21F8506 for ; Thu, 24 Jan 2013 11:00:09 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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 D0B872026F; Thu, 24 Jan 2013 13:56:27 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3A13B43FD; Thu, 24 Jan 2013 14:00:07 -0500 (EST)
From: Sam Hartman 
To: Dave Nelson 
References:    <5101573B.8080409@deployingradius.com>  <5101600C.7020906@deployingradius.com>  <51018045.8010605@deployingradius.com>  
Date: Thu, 24 Jan 2013 14:00:07 -0500
In-Reply-To:  (Dave Nelson's message of "Thu, 24 Jan 2013 13:58:00 -0500")
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: siva kumar , Bernard Aboba , radext@ietf.org, Alan DeKok 
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 19:00:11 -0000

>>>>> "Dave" == Dave Nelson  writes:

    Dave> On Thu, Jan 24, 2013 at 1:49 PM, Sam Hartman
    Dave>  wrote:

> I think a NAS should treat such an unexpected attribute as if it had not
    >> been present in the packet.

    Dave> That might be OK for Access-Challenge packets.  RFC 5080
    Dave> Section 2.5 says this is a really bad idea for Access-Accept
    Dave> packets.

I was speaking specifically to access-challenge.
I'm not sure I agree with  RFc 5080 here, but I think the tradeoff is
more complex.

From dnelson@elbrys.com  Thu Jan 24 11:02:09 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E867921F8566 for ; Thu, 24 Jan 2013 11:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 rNnRs+lTnHHO for ; Thu, 24 Jan 2013 11:02:09 -0800 (PST)
Received: from mail-we0-x236.google.com (we-in-x0236.1e100.net [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2D15021F8506 for ; Thu, 24 Jan 2013 11:02:08 -0800 (PST)
Received: by mail-we0-f182.google.com with SMTP id t57so461958wey.27 for ; Thu, 24 Jan 2013 11:02:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=eVOyMOTqHkaQRF2SJBbHEc66O+4HCGPLs/1dyXJvR+k=; b=JwIaGIUXsNpXTdw8SgVhpICTPpOhifr2NrEVOr1HkF7s4T+dHegIAcaaJ4r0EiBhsX Sq+456st0bfUioTVtTkkwzl64HJIalgvW+QH92nvsfvrk4Vhe63AflPgEQy4o4+MGhEi wlAyS+0Cu/WyTTiKGjndIUn0I7WkQeZRAPeRVEyoouC4khTTP6dEaB8iSBKJ4sIZhEno xFeD6JKjP4QD+1zMGe9ck9ZbUfarzKEmhYN+zexHeJfbWi51Iru5Ti9mdOi60e/hnKGW 2Z0qFmwkNaURrM+zmPCOuR2PA1Z13G64cQV5tMc+Uip9ga0puiKJba/EfM3xoETj+MzK UhXQ==
MIME-Version: 1.0
X-Received: by 10.180.77.68 with SMTP id q4mr4914108wiw.10.1359054128061; Thu, 24 Jan 2013 11:02:08 -0800 (PST)
Received: by 10.194.124.107 with HTTP; Thu, 24 Jan 2013 11:02:08 -0800 (PST)
In-Reply-To: 
References:    <5101573B.8080409@deployingradius.com>  <5101600C.7020906@deployingradius.com>  <51018045.8010605@deployingradius.com>   
Date: Thu, 24 Jan 2013 14:02:08 -0500
Message-ID: 
From: Dave Nelson 
To: Sam Hartman 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlL/9DigI3O8ILroC+XDc98+Y/GYLbGQXGRWFWfiGvCj2EB+mo/FXy2u0CBqir5QRgtr/+I
Cc: siva kumar , Bernard Aboba , radext@ietf.org, Alan DeKok 
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 19:02:10 -0000

On Thu, Jan 24, 2013 at 2:00 PM, Sam Hartman
 wrote:

>... I think the tradeoff is more complex.

As it almost always is between easy interoperability and security.  :-)

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

From bernard_aboba@hotmail.com  Thu Jan 24 11:18:36 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9050B21F868E for ; Thu, 24 Jan 2013 11:18:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.217
X-Spam-Level: 
X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152, 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 NI8JoRFAXruk for ; Thu, 24 Jan 2013 11:18:35 -0800 (PST)
Received: from blu0-omc1-s28.blu0.hotmail.com (blu0-omc1-s28.blu0.hotmail.com [65.55.116.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4660021F8682 for ; Thu, 24 Jan 2013 11:18:26 -0800 (PST)
Received: from BLU403-EAS178 ([65.55.116.7]) by blu0-omc1-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 24 Jan 2013 11:18:25 -0800
X-EIP: [gXr8HxsTGOf56JnnUe5FkUPGYoHmWNb1Wyy/R4aVXsc=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
MIME-Version: 1.0
From: Bernard Aboba 
To: =?utf-8?Q?Alan_DeKok?= ,  =?utf-8?Q?Dave_Nelson?= 
Importance: Normal
Date: Thu, 24 Jan 2013 19:18:24 +0000
Content-Type: multipart/alternative; boundary="_38E78FD2-50EF-46BB-8D63-CCD0149AF578_"
X-OriginalArrivalTime: 24 Jan 2013 19:18:25.0486 (UTC) FILETIME=[952BBEE0:01CDFA67]
Cc: =?utf-8?Q?siva_kumar?= , "=?utf-8?Q?radext@ietf.org?=" 
Subject: Re: [radext] =?utf-8?q?rfc3579-_Doubt_regarding_Access_challenge_pack?= =?utf-8?q?et?=
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, 24 Jan 2013 19:18:36 -0000

--_38E78FD2-50EF-46BB-8D63-CCD0149AF578_
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"

W0JBXSBUaGF0IHRleHQgaXMgYWJvdXQgQWNjZXNzLUFjY2VwdCwgbm90IEFjY2Vzcy1DaGFsbGVu
Z2UuICBBbiBBY2Nlc3MtQ2hhbGxlbmdlIGlzIG5vdCBhYm91dCBwcm92aXNpb25pbmcgc2Vydmlj
ZXMgKHRoZSBkZWNpc2lvbiBvbiB3aGV0aGVyIHRvIEFjY2VwdCBvciBSZWplY3QgaGFzIG5vdCBi
ZWVuIG1hZGUgeWV0KS4gIEdpdmVuIHRoYXQsIEkgYmVsaWV2ZSB0aGF0IGlnbm9yaW5nIGF0dHJp
YnV0ZXMgdGhhdCBhcmVuJ3QgdW5kZXJzdG9vZCBpcyBwcm9iYWJseSBmaW5lLiAgRXZlbiBhdHRy
aWJ1dGVzIHRoYXQgbWlnaHQgYmUgY29uc2lkZXJlZCBtYW5kYXRvcnkgaW4gYW4gQWNjZXB0IChl
LmcuIGZpbHRlcnMpIGNhbiBwcm9iYWJseSBiZSBzYWZlbHkgaWdub3JlZCBpbiBhbiBBY2Nlc3Mt
Q2hhbGxlbmdlLiANCg0KIA0KDQoNCiANCg0KIA0KDQogDQoNCiANCg0KIA0KDQoNCg0KU2VjdGlv
biAyLjUgb2YgUkZDIDUwODAgc2F5cywgaW4gcmVsZXZhbnQgcGFydDoNCg0KICAgSW4gZ2VuZXJh
bCwgaXQgaXMgYmVzdCBmb3IgYSBSQURJVVMgY2xpZW50IHRvIGVyciBvbiB0aGUgc2lkZSBvZg0K
ICAgY2F1dGlvbi4gIE9uIHJlY2VpdmluZyBhbiBBY2Nlc3MtQWNjZXB0IGluY2x1ZGluZyBhbiBh
dHRyaWJ1dGUgb2YNCiAgIGtub3duIFR5cGUgZm9yIGFuIHVuaW1wbGVtZW50ZWQgc2VydmljZSwg
YSBSQURJVVMgY2xpZW50IE1VU1QgdHJlYXQNCiAgIGl0IGFzIGFuIEFjY2Vzcy1SZWplY3QsIGFz
IGRpcmVjdGVkIGluIFtSRkMyODY1XSBTZWN0aW9uIDEuMS4gIE9uDQogICByZWNlaXZpbmcgYW4g
QWNjZXNzLUFjY2VwdCBpbmNsdWRpbmcgYW4gYXR0cmlidXRlIG9mIHVua25vd24gVHlwZSwgYQ0K
ICAgUkFESVVTIGNsaWVudCBTSE9VTEQgYXNzdW1lIHRoYXQgaXQgaXMgYSBwb3RlbnRpYWwgc2Vy
dmljZQ0KICAgZGVmaW5pdGlvbiwgYW5kIHRyZWF0IGl0IGFzIGFuIEFjY2Vzcy1SZWplY3QuICBV
bmtub3duIFZTQXMgU0hPVUxEIGJlDQogICBpZ25vcmVkIGJ5IFJBRElVUyBjbGllbnRzLg0KDQog
ICBJbiBvcmRlciB0byBhdm9pZCBpbnRyb2R1Y2luZyBjaGFuZ2VzIGluIGRlZmF1bHQgYmVoYXZp
b3IsIGV4aXN0aW5nDQogICBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBub3Qgb2JleSB0aGlzIHJl
Y29tbWVuZGF0aW9uIHNob3VsZCBtYWtlIHRoZQ0KICAgYmVoYXZpb3IgY29uZmlndXJhYmxlLCB3
aXRoIHRoZSBsZWdhY3kgYmVoYXZpb3IgYmVpbmcgZW5hYmxlZCBieQ0KICAgZGVmYXVsdC4gIEEg
Y29uZmlndXJhdGlvbiBmbGFnIHN1Y2ggYXMgInRyZWF0IHVua25vd24gYXR0cmlidXRlcyBhcw0K
ICAgcmVqZWN0IiBjYW4gYmUgZXhwb3NlZCB0byB0aGUgc3lzdGVtIGFkbWluaXN0cmF0b3IuICBJ
ZiB0aGUgZmxhZyBpcw0KICAgc2V0IHRvIHRydWUsIHRoZW4gQWNjZXNzLUFjY2VwdHMgY29udGFp
bmluZyB1bmtub3duIGF0dHJpYnV0ZXMgYXJlDQogICB0cmVhdGVkIGFzIEFjY2Vzcy1SZWplY3Rz
LiAgSWYgdGhlIGZsYWcgaXMgc2V0IHRvIGZhbHNlLCB0aGVuIHVua25vd24NCiAgIGF0dHJpYnV0
ZXMgaW4gQWNjZXNzLUFjY2VwdHMgYXJlIHNpbGVudGx5IGlnbm9yZWQuDQoNClJlZ2FyZHMsDQoN
CkRhdmUNCg0KRGF2aWQgQi4gTmVsc29uDQpEaXJlY3RvciBvZiBUZWNobm9sb2d5DQpFbGJyeXMg
TmV0d29ya3MsIEluYy4NCnd3dy5lbGJyeXMuY29tDQorMS42MDMuNTcwLjI2MzY=

--_38E78FD2-50EF-46BB-8D63-CCD0149AF578_
Content-Transfer-Encoding: base64
Content-Type: text/html; charset="utf-8"

PGh0bWw+PGhlYWQ+PHN0eWxlIGRhdGEtZXh0ZXJuYWxzdHlsZT0idHJ1ZSI+CnAuTXNvTGlzdFBh
cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGggewptYXJn
aW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1s
ZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKfQoKcC5Nc29MaXN0UGFyYWdyYXBoQ3hT
cEZpcnN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBkaXYuTXNvTGlzdFBhcmFncmFw
aEN4U3BGaXJzdCwgcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFn
cmFwaEN4U3BNaWRkbGUsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgcC5Nc29MaXN0
UGFyYWdyYXBoQ3hTcExhc3QsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgZGl2Lk1zb0xp
c3RQYXJhZ3JhcGhDeFNwTGFzdCB7Cm1hcmdpbi10b3A6MGluOwptYXJnaW4tcmlnaHQ6MGluOwpt
YXJnaW4tYm90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0
OwpsaW5lLWhlaWdodDoxMTUlOwp9Cjwvc3R5bGU+PHN0eWxlPjwhLS0KLkVtYWlsUXVvdGUgewpw
YWRkaW5nLWxlZnQ6NHB0OwptYXJnaW4tbGVmdDoxcHQ7CmJvcmRlci1sZWZ0LWNvbG9yOnJnYigx
MjgsIDAsIDApOwpib3JkZXItbGVmdC13aWR0aDoycHg7CmJvcmRlci1sZWZ0LXN0eWxlOnNvbGlk
Owp9Ci0tPjwvc3R5bGU+PC9oZWFkPjxib2R5PjxkaXYgZGF0YS1leHRlcm5hbHN0eWxlPSJmYWxz
ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksJ1NlZ29lIFVJJyxNZWlyeW8sJ01pY3Jvc29m
dCBZYUhlaSBVSScsJ01pY3Jvc29mdCBKaGVuZ0hlaSBVSScsJ01hbGd1biBHb3RoaWMnLCdLaG1l
ciBVSScsJ05pcm1hbGEgVUknLFR1bmdhLCdMYW8gVUknLEVicmltYSxzYW5zLXNlcmlmO2ZvbnQt
c2l6ZToxNnB4OyI+PGRpdj5bQkFdIFRoYXQgdGV4dCBpcyBhYm91dCBBY2Nlc3MtQWNjZXB0LCBu
b3QgQWNjZXNzLUNoYWxsZW5nZS4mbmJzcDsgQW4gQWNjZXNzLUNoYWxsZW5nZSBpcyBub3QgYWJv
dXQgcHJvdmlzaW9uaW5nIHNlcnZpY2VzICh0aGUgZGVjaXNpb24gb24gd2hldGhlciB0byBBY2Nl
cHQgb3IgUmVqZWN0IGhhcyBub3QgYmVlbiBtYWRlIHlldCkuJm5ic3A7IEdpdmVuIHRoYXQsIEkg
YmVsaWV2ZSB0aGF0IGlnbm9yaW5nIGF0dHJpYnV0ZXMgdGhhdCBhcmVuJ3QgdW5kZXJzdG9vZCBp
cyBwcm9iYWJseSBmaW5lLiZuYnNwOyBFdmVuIGF0dHJpYnV0ZXMgdGhhdCBtaWdodCBiZSBjb25z
aWRlcmVkIG1hbmRhdG9yeSBpbiBhbiBBY2NlcHQgKGUuZy4gZmlsdGVycykgY2FuIHByb2JhYmx5
IGJlIHNhZmVseSBpZ25vcmVkIGluIGFuIEFjY2Vzcy1DaGFsbGVuZ2UuIDwvZGl2Pjxmb250IHNp
emU9IjIiPjxkaXY+Jm5ic3A7PC9kaXY+PGRpdiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUi
PjxkaXYgZGF0YS1zaWduYXR1cmVibG9jaz0idHJ1ZSI+Jm5ic3A7PC9kaXY+PC9kaXY+PGRpdiBk
YXRhLXNpZ25hdHVyZWJsb2NrPSJ0cnVlIj4mbmJzcDs8L2Rpdj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOiAxMHB0OyI+PGRpdiBkYXRhLXNpZ25hdHVyZWJsb2NrPSJ0cnVlIj4mbmJzcDs8L2Rpdj48
ZGl2IGRhdGEtZm9jdXNmcm9tcG9pbnRlcj0idHJ1ZSI+Jm5ic3A7PC9kaXY+PGRpdiBkYXRhLWZv
Y3VzZnJvbXBvaW50ZXI9InRydWUiPiZuYnNwOzwvZGl2PjxkaXYgZGF0YS1zaWduYXR1cmVibG9j
az0idHJ1ZSI+Jm5ic3A7PC9kaXY+PGRpdiBjbGFzcz0iIFBsYWluVGV4dCI+PGJyPgpTZWN0aW9u
IDIuNSBvZiBSRkMgNTA4MCBzYXlzLCBpbiByZWxldmFudCBwYXJ0Ojxicj4KPGJyPgombmJzcDsm
bmJzcDsgSW4gZ2VuZXJhbCwgaXQgaXMgYmVzdCBmb3IgYSBSQURJVVMgY2xpZW50IHRvIGVyciBv
biB0aGUgc2lkZSBvZjxicj4KJm5ic3A7Jm5ic3A7IGNhdXRpb24uJm5ic3A7IE9uIHJlY2Vpdmlu
ZyBhbiBBY2Nlc3MtQWNjZXB0IGluY2x1ZGluZyBhbiBhdHRyaWJ1dGUgb2Y8YnI+CiZuYnNwOyZu
YnNwOyBrbm93biBUeXBlIGZvciBhbiB1bmltcGxlbWVudGVkIHNlcnZpY2UsIGEgUkFESVVTIGNs
aWVudCBNVVNUIHRyZWF0PGJyPgombmJzcDsmbmJzcDsgaXQgYXMgYW4gQWNjZXNzLVJlamVjdCwg
YXMgZGlyZWN0ZWQgaW4gW1JGQzI4NjVdIFNlY3Rpb24gMS4xLiZuYnNwOyBPbjxicj4KJm5ic3A7
Jm5ic3A7IHJlY2VpdmluZyBhbiBBY2Nlc3MtQWNjZXB0IGluY2x1ZGluZyBhbiBhdHRyaWJ1dGUg
b2YgdW5rbm93biBUeXBlLCBhPGJyPgombmJzcDsmbmJzcDsgUkFESVVTIGNsaWVudCBTSE9VTEQg
YXNzdW1lIHRoYXQgaXQgaXMgYSBwb3RlbnRpYWwgc2VydmljZTxicj4KJm5ic3A7Jm5ic3A7IGRl
ZmluaXRpb24sIGFuZCB0cmVhdCBpdCBhcyBhbiBBY2Nlc3MtUmVqZWN0LiZuYnNwOyBVbmtub3du
IFZTQXMgU0hPVUxEIGJlPGJyPgombmJzcDsmbmJzcDsgaWdub3JlZCBieSBSQURJVVMgY2xpZW50
cy48YnI+Cjxicj4KJm5ic3A7Jm5ic3A7IEluIG9yZGVyIHRvIGF2b2lkIGludHJvZHVjaW5nIGNo
YW5nZXMgaW4gZGVmYXVsdCBiZWhhdmlvciwgZXhpc3Rpbmc8YnI+CiZuYnNwOyZuYnNwOyBpbXBs
ZW1lbnRhdGlvbnMgdGhhdCBkbyBub3Qgb2JleSB0aGlzIHJlY29tbWVuZGF0aW9uIHNob3VsZCBt
YWtlIHRoZTxicj4KJm5ic3A7Jm5ic3A7IGJlaGF2aW9yIGNvbmZpZ3VyYWJsZSwgd2l0aCB0aGUg
bGVnYWN5IGJlaGF2aW9yIGJlaW5nIGVuYWJsZWQgYnk8YnI+CiZuYnNwOyZuYnNwOyBkZWZhdWx0
LiZuYnNwOyBBIGNvbmZpZ3VyYXRpb24gZmxhZyBzdWNoIGFzICJ0cmVhdCB1bmtub3duIGF0dHJp
YnV0ZXMgYXM8YnI+CiZuYnNwOyZuYnNwOyByZWplY3QiIGNhbiBiZSBleHBvc2VkIHRvIHRoZSBz
eXN0ZW0gYWRtaW5pc3RyYXRvci4mbmJzcDsgSWYgdGhlIGZsYWcgaXM8YnI+CiZuYnNwOyZuYnNw
OyBzZXQgdG8gdHJ1ZSwgdGhlbiBBY2Nlc3MtQWNjZXB0cyBjb250YWluaW5nIHVua25vd24gYXR0
cmlidXRlcyBhcmU8YnI+CiZuYnNwOyZuYnNwOyB0cmVhdGVkIGFzIEFjY2Vzcy1SZWplY3RzLiZu
YnNwOyBJZiB0aGUgZmxhZyBpcyBzZXQgdG8gZmFsc2UsIHRoZW4gdW5rbm93bjxicj4KJm5ic3A7
Jm5ic3A7IGF0dHJpYnV0ZXMgaW4gQWNjZXNzLUFjY2VwdHMgYXJlIHNpbGVudGx5IGlnbm9yZWQu
PGJyPgo8YnI+ClJlZ2FyZHMsPGJyPgo8YnI+CkRhdmU8YnI+Cjxicj4KRGF2aWQgQi4gTmVsc29u
PGJyPgpEaXJlY3RvciBvZiBUZWNobm9sb2d5PGJyPgpFbGJyeXMgTmV0d29ya3MsIEluYy48YnI+
CjxhIHRhYmluZGV4PSItMSIgaHJlZj0iaHR0cDovL3d3dy5lbGJyeXMuY29tIj53d3cuZWxicnlz
LmNvbTwvYT48YnI+CisxLjYwMy41NzAuMjYzNjxicj4KPC9kaXY+PC9zcGFuPjwvZm9udD4KCgo8
L2Rpdj48L2JvZHk+PC9odG1sPg==

--_38E78FD2-50EF-46BB-8D63-CCD0149AF578_--

From dnelson@elbrys.com  Thu Jan 24 11:27:29 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BEC11E8097 for ; Thu, 24 Jan 2013 11:27:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 caffDdUdkKF0 for ; Thu, 24 Jan 2013 11:27:29 -0800 (PST)
Received: from mail-wg0-x22a.google.com (wg-in-x022a.1e100.net [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BBC9B21F85EA for ; Thu, 24 Jan 2013 11:27:28 -0800 (PST)
Received: by mail-wg0-f42.google.com with SMTP id 12so577958wgh.1 for ; Thu, 24 Jan 2013 11:27:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=b1PD1a6yezoB7HAWpcaZ8kZlfUmFp/xiAnlE2QfpflE=; b=a7ibVP1t4yovlpWaGPePm7ZtFokJc2eN1UtdKhdox5HoadXRVyIVhOFsdh++k+4q2w d9UnnztyFsfa8uZagMojvkzL1zohluLHoA2lHtNqtuZ3Pu4MjHKRTMHaRZCdNm5DENra P9mj4TKp0hYsVirkI+Nk0O7a5JnEKCw0QvrIaqSK/aTxzvk6mGnZ9KEoNi6Cbhwv3iyP 8Nbfr/GxEoQICPm70BMi6Zk6EvkA6/dNgtm2iOq5e8pKzVtAg7beikC1A6uT5GGMRvfs urpKBHrEkercP46R2n22KJTiTBr7MXgG5eb7Ms7c2sSYkRyrEbVdvRzLvjJ74QMnpuCx mZ8w==
MIME-Version: 1.0
X-Received: by 10.194.71.244 with SMTP id y20mr5145639wju.19.1359055647685; Thu, 24 Jan 2013 11:27:27 -0800 (PST)
Received: by 10.194.124.107 with HTTP; Thu, 24 Jan 2013 11:27:27 -0800 (PST)
In-Reply-To: 
References: 
Date: Thu, 24 Jan 2013 14:27:27 -0500
Message-ID: 
From: Dave Nelson 
To: Bernard Aboba 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkxMCyvctCZzqd2X+MoKDoxiTrCvjJjOLSYDag9FMJ4RLCqXIPVJfAJIBF4WctY0rbb0/TU
Cc: siva kumar , "radext@ietf.org" , Alan DeKok 
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 24 Jan 2013 19:27:29 -0000

On Thu, Jan 24, 2013 at 2:18 PM, Bernard Aboba
 wrote:

> [BA] That text is about Access-Accept, not Access-Challenge.  An
> Access-Challenge is not about provisioning services (the decision on whether
> to Accept or Reject has not been made yet).  Given that, I believe that
> ignoring attributes that aren't understood is probably fine.  Even
> attributes that might be considered mandatory in an Accept (e.g. filters)
> can probably be safely ignored in an Access-Challenge.

Agreed.

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

From diego@tid.es  Thu Jan 24 15:37:34 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92EA11E8099; Thu, 24 Jan 2013 15:37:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.338
X-Spam-Level: 
X-Spam-Status: No, score=-4.338 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_XBL=3.033]
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 qS5rVkSFi7U3; Thu, 24 Jan 2013 15:37:34 -0800 (PST)
Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id C4AB321F8BD0; Thu, 24 Jan 2013 15:37:27 -0800 (PST)
Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MH5009KTLLW2C@tid.hi.inet>; Fri, 25 Jan 2013 00:37:25 +0100 (MET)
Received: from vanvan (vanvan.hi.inet [10.95.78.49])	by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 90.16.02896.4B5C1015; Fri, 25 Jan 2013 00:37:25 +0100 (CET)
Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MH5009MQLMC2C@tid.hi.inet>; Fri, 25 Jan 2013 00:37:24 +0100 (MET)
Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0328.009; Fri, 25 Jan 2013 00:37:24 +0100
Date: Thu, 24 Jan 2013 23:37:24 +0000
From: "Diego R. Lopez" 
In-reply-to: <51015859.4010008@deployingradius.com>
X-Originating-IP: [10.95.64.115]
To: Alan DeKok 
Message-id: 
Content-id: <95B96DAD44F38D4D8F8C3A4D1E302CBC@hi.inet>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: base64
Accept-Language: en-US
Thread-topic: [abfab] [radext] Fwd: New Version Notification	for draft-perez-radext-radius-fragmentation-04.txt
Thread-index: AQHN+krqQs18zK84tUOgrlXG2ixR0ZhZEiuA
X-AuditID: 0a5f4e69-b7f636d000000b50-d6-5101c5b4f346
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRmVeSWpSXmKPExsXCFe9nqLv1KGOgwfFbLBYfr79htGh5NZPN gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZc3cbFtzirTg+7SxbA+Ma3i5GDg4JAROJVVOzuxg5 gUwxiQv31rN1MXJxCAlsY5T4u/8WE4TzlFGif8IpFghnJqPEg62rGUFaWARUJT49mscGYrMB 2Y+af7OD2MICBRKHF3eygticAsYSW9ddY4JYoSDx59xjFhBbREBLYsH6RWA2s0CVRO+5E2D1 vALeEs9WvmGEiJtJnJg+nx0iLijxY/I9FpCrmQXUJaZMyYUoEZdobr0JNUZRYtqiBrBWRqBv vp9awwSxqlDi5q1mdgjbSGJF42c2iHMEJJbsOc8MYYtKvHz8D+wEIYG5jBIt51kmMErMQnLF LCRXzEK4YhaSK2YhuWIBI+sqRrHipKLM9IyS3MTMnHQDI72MTL3MvNSSTYyQ2Mvcwbh8p8oh RgEORiUe3oo7/wOEWBPLiitzDzFKcjApifJu28cYKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE 1yUCKMebklhZlVqUD5OS4eBQkuBdegQoJViUmp5akZaZA0wwMGkmDk6Qdh6QdpAa3uKCxNzi zHSI/ClGSSlx3u0gCQGQREZpHlzvK0ZxoCOFebtBsjzAVAjX9QpoIBPQwP2zgM7nLS5JREhJ NTCG19rPVxRc+yNlj234DRvDm5Y/JNSqsgXcs4JqvIzittzIr2rRuLlv272KdnF3rwJxSZXf Od9vdepXx5xK27/KU3rl/90BAjknOLXU/351+ZVTxtzY4KxjsOlUONMc++UB9c4On3M3f4jN 2pIwZerrnzbromcxS1pv+xB3o35VxqJuzfjoxUosxRmJhlrMRcWJANp8GB9CAwAA
References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es>  <51015859.4010008@deployingradius.com>
Cc: Sam Hartman , "abfab@ietf.org" , "radext@ietf.org" 
Subject: Re: [radext] [abfab] Fwd: New Version Notification	for	draft-perez-radext-radius-fragmentation-04.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, 24 Jan 2013 23:37:34 -0000

DQpPbiAyNCBKYW4gMjAxMywgYXQgMTY6NTAgLCBBbGFuIERlS29rIHdyb3RlOg0KDQo+IFNhbSBI
YXJ0bWFuIHdyb3RlOg0KPj4gVGhpcyBzb3VuZHMgZ3JlYXQuDQo+PiBXaGF0J3MgdGhlIHN0YXRl
IHdpdGhpbiByYWRleHQ/DQo+PiBJIGtub3cgaXQncyBub3cgY2hhcnRlcmVkOyBob3cgY2FuIHdl
IGhlbHAgZ2V0IHRoaXMgYWRvcHRlZD8NCj4NCj4gIFBpcGUgdXAgaW4gcmFkZXh0LiAgSXQncyBv
biB0aGUgUkFERVhUIGNoYXJ0ZXIgbm93LiAgU28gd2UnbGwgbmVlZA0KPiByZXZpZXdlcnMsIGFu
ZCBhIGNhbGwgZm9yIFdHIGFkb3B0aW9uLg0KPg0KQXQgdGhlIGxhc3QgUkFERVhUIG1lZXRpbmcg
dGhlIGNhbGwgZm9yIHJldmlld2VycyB3YXMgbWFkZSwgdHdvIHJldmlld2Vycw0KaWRlbnRpZmll
ZCAoQWxleCBoYXMgY29udGFjdGVkIHRoZW0gb25jZSB0aGUgbGF0ZXN0IHZlcnNpb24gd2FzIGF2
YWlsYWJsZSkNCnNvIFdHIGFkb3B0aW9uIHNob3VsZCBiZSBjbG9zZS4NCg0KQlRXLCB0aGUgaW1w
bGVtZW50YXRpb24gb2YgYSBQb0MgaXMgZmluaXNoZWQgYW5kIHdlIGFyZSBkaXNjdXNzaW5nIGhv
dw0KdG8gbWFrZSBhIGRlbW8gb2YgaXQgYW55dGltZSBzb29uIChzb3JyeSBmb3IgdGhlIHNwb2ls
ZXIsIHlvdSBVTVUgZ3V5cykNCg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFy
ZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJ
K0QNCmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvQHRp
ZC5lcw0KVGVsOiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZh
bWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGlj
YSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5s
YWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNp
dmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9u
IHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VT
L1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo=

From ietf@augustcellars.com  Thu Jan 24 16:56:59 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E7C1F0CE4 for ; Thu, 24 Jan 2013 16:56:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.274
X-Spam-Level: 
X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325,  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 SRhtjL1o4Ddm for ; Thu, 24 Jan 2013 16:56:58 -0800 (PST)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD261F0CB3 for ; Thu, 24 Jan 2013 16:56:58 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id BF0D738F27; Thu, 24 Jan 2013 16:56:57 -0800 (PST)
From: "Jim Schaad" 
To: 
Date: Thu, 24 Jan 2013 16:56:29 -0800
Message-ID: <005b01cdfa96$d2f173d0$78d45b70$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac36gVony5sg1ydWRv+ksunU9EeNsA==
Content-Language: en-us
Cc: radext@ietf.org
Subject: [radext] Comments on draft-perez-radext-radius-fragmentation-04
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, 25 Jan 2013 00:56:59 -0000

First, I would like the chairs to issue an adoption call on this document so
we can formally work on it.

Comments on the draft itself.

1.  I just did a count on the number attributes in the example for
Access-Request-1 and came up with a count of 9.  This exceeds the posited
maximum length of 8 that the example is using as a limitation.

2.  In section 5.1 - although this is going to be unusual behavior, a proxy
could remove Proxy-State attributes and keep them for later re-insertion.  I
can imagine that this behavior, while legal, could cause all sorts of
problems on a packet coming back because the SA could end up putting too
many bytes in the packet.  Does this need to be documented?

3.  In section 5.1 - Should there be some suggestions about doing retries
for chucked objects based on a timeout in the case of a proxy dropping it?

4.  In section 5.3 -- Alan - we had several discussions in Atlanta about the
interactions of a SAML authorization query combining with an EAP message.  I
think that we finally decided that since we could fragment the first
response there were no big issues involved any more.  Is my memory still
correct on this question?

5.  In section 5.3 - I am not sure why there is a requirement that these
attributes be in the same fragmentation packet.  The server SHOULD NOT start
processing the contents of the sent packet until such a time as entirety of
the full packet has been received, so unless a proxy is going to operate on
these attributes I don't see the point of this.

6. In section 5.3 - I think you need to make it explicit that for
Message-Authenticator, it is the fragment message that will be authenticated
not the entire unfragmented message.

7.  In section 5.4 - You need to document what happens with the ID attribute
as well.  (Always last?)

8.  In section 6.1 - It must not be in Access-Reject packets as well.
Should that be documented?  (also s/MUST not/MUST NOT/)

9.  In section 6.2 - see previous comments

10.  In section 6.3 - the table appears to be wrong.  I think the that
Proxy-State-Len should be 0 under the Acc column.

11.  In Section 8 - I think there is a potential security consideration that
may need to be added.  As the system is currently defined, if the
Message-Authenticator attribute is in the original message, it is not made a
requirement of all the fragments in the system.  This means that only a
subset of the original message will be authenticated.  This is a definite
security change.

12.  In section 9 - No IANA actions?  What about the required registrations?

Spelling errors

s/Acess-Request-2/Access-Request-2/
s/size of he RADIUS/size of the RADIUS/
s/should they cannot add/should they be unable to add/
s/how many space/how much space/

jim



From shiv.annauniv@gmail.com  Thu Jan 24 22:59:03 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B903821F85C0 for ; Thu, 24 Jan 2013 22:59:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 QyJM+YFn2tqX for ; Thu, 24 Jan 2013 22:59:03 -0800 (PST)
Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id 09AA021F848B for ; Thu, 24 Jan 2013 22:59:02 -0800 (PST)
Received: by mail-vc0-f169.google.com with SMTP id n10so35598vcn.0 for ; Thu, 24 Jan 2013 22:59:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yR9q1PkDr4EQw54DevxdBC0yqvFeLPZ/Hqv5O50KaAQ=; b=GSHzM+QjCxtdoMX8JbeAsfepkIGPcCWud1JnMeLybO4d7hwu5IcU1v0i+ikKcZV+l1 WCQggpXQGCtNkS9CUa7p4aJfjQBhNpaByIaCL/eGTWYK9bDkAIXrTOarknwcm+wnkna2 Zs/CbWHGSp6Yg1xU84M5ExQuJnmqjnUOAbzyTo8FktlrB9qIQ9Wks72xgleCI6yin3VK fTbznOAsYCeGEM2Z7IFvWDZKRWba1WtN6KRyxgwvqqrK68Z8SleHkz8GcH/9aEcfr+dQ 51YrTmqNo3OzXh7SEa1l3UcByv5zyMensVSrToKmkDyU036CPr58MKpqEHQoKB3npKSH ewOw==
MIME-Version: 1.0
X-Received: by 10.220.154.66 with SMTP id n2mr4960736vcw.40.1359097142440; Thu, 24 Jan 2013 22:59:02 -0800 (PST)
Received: by 10.220.155.208 with HTTP; Thu, 24 Jan 2013 22:59:02 -0800 (PST)
In-Reply-To: 
References:  
Date: Fri, 25 Jan 2013 12:29:02 +0530
Message-ID: 
From: siva kumar 
To: Dave Nelson 
Content-Type: multipart/alternative; boundary=f46d043be0b063f1db04d417763c
X-Mailman-Approved-At: Thu, 24 Jan 2013 23:43:33 -0800
Cc: Bernard Aboba , "radext@ietf.org" , Alan DeKok 
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 25 Jan 2013 07:00:48 -0000

--f46d043be0b063f1db04d417763c
Content-Type: text/plain; charset=ISO-8859-1

Hi Dave/Alan/Bernard/Others,

Thanks all for the valuable inputs. It is evident that our NAS
implementation is not acceptable as per your views. And Our NAS
is not interoperable with most of the radius servers. We will consider all
your inputs and re-architect our implementation.

Thanks again.

Regards,
Sivakumar.S

On Fri, Jan 25, 2013 at 12:57 AM, Dave Nelson  wrote:

> On Thu, Jan 24, 2013 at 2:18 PM, Bernard Aboba
>  wrote:
>
> > [BA] That text is about Access-Accept, not Access-Challenge.  An
> > Access-Challenge is not about provisioning services (the decision on
> whether
> > to Accept or Reject has not been made yet).  Given that, I believe that
> > ignoring attributes that aren't understood is probably fine.  Even
> > attributes that might be considered mandatory in an Accept (e.g. filters)
> > can probably be safely ignored in an Access-Challenge.
>
> Agreed.
>
> Regards,
>
> Dave
>
> David B. Nelson
> Director of Technology
> Elbrys Networks, Inc.
> www.elbrys.com
> +1.603.570.2636
>

--f46d043be0b063f1db04d417763c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Dave/Alan/Bernard/Others,

Thanks all for the valuable inputs. It =
is evident that our NAS implementation is not acceptable as per your views.=
 And Our NAS
is not interoperable with most of the radius servers. We wi=
ll consider all your inputs and re-architect our implementation.


Thanks again.

Regards,
Sivakumar.S

On Fri, Jan 25, 2013 at 12:57 AM, Dave Nelson <=
;dnelson@elbrys.com=
> wrote:


On Thu,=
 Jan 24, 2013 at 2:18 PM, Bernard Aboba

<bernard_aboba@hotmail.com<=
/a>> wrote:



> [BA] That text is about Access-Accept, not Access-Challenge. =A0An

> Access-Challenge is not about provisioning services (the decision on w=
hether

> to Accept or Reject has not been made yet). =A0Given that, I believe t=
hat

> ignoring attributes that aren't understood is probably fine. =A0Ev=
en

> attributes that might be considered mandatory in an Accept (e.g. filte=
rs)

> can probably be safely ignored in an Access-Challenge.




Agreed.




Regards,



Dave



David B. Nelson

Director of Technology

Elbrys Networks, Inc.

www.elbrys.com

+1.603.570.2636





--f46d043be0b063f1db04d417763c--

From alex@um.es  Fri Jan 25 01:09:22 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF52121F8870 for ; Fri, 25 Jan 2013 01:09:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.798
X-Spam-Level: 
X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 U0rJV5Tck5W3 for ; Fri, 25 Jan 2013 01:09:21 -0800 (PST)
Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id E7C8B21F865D for ; Fri, 25 Jan 2013 01:09:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 4790F5D55B; Fri, 25 Jan 2013 10:09:18 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon13.um.es
Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lbpr2Eg0J4BY; Fri, 25 Jan 2013 10:09:17 +0100 (CET)
Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPSA id EAE935D51C; Fri, 25 Jan 2013 10:09:15 +0100 (CET)
Message-ID: <51024BBA.3020009@um.es>
Date: Fri, 25 Jan 2013 10:09:14 +0100
From: Alejandro Perez Mendez 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jim Schaad 
References: <005b01cdfa96$d2f173d0$78d45b70$@augustcellars.com>
In-Reply-To: <005b01cdfa96$d2f173d0$78d45b70$@augustcellars.com>
Content-Type: multipart/alternative; boundary="------------090604040602000905080109"
Cc: radext@ietf.org, draft-perez-radext-radius-fragmentation@tools.ietf.org
Subject: Re: [radext] Comments on draft-perez-radext-radius-fragmentation-04
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, 25 Jan 2013 09:09:23 -0000

This is a multi-part message in MIME format.
--------------090604040602000905080109
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Jim,

thanks for your valuable comments, let me try to answer to some of them 
inline.

> First, I would like the chairs to issue an adoption call on this document so
> we can formally work on it.
>
> Comments on the draft itself.
>
> 1.  I just did a count on the number attributes in the example for
> Access-Request-1 and came up with a count of 9.  This exceeds the posited
> maximum length of 8 that the example is using as a limitation.

You counted the ID field, which is represented as an attribute for 
simplicity, though it is not. Prior describing the example it is said that

    The Identifier field is denoted as IDX, even though it is
        not an attribute.

I could either change the notation, add a better explanatory paragraph 
or just count it as an attribute for sake of simplicity again and say 
the limit is 9 attributes instead of 8.


> 2.  In section 5.1 - although this is going to be unusual behavior, a proxy
> could remove Proxy-State attributes and keep them for later re-insertion.  I
> can imagine that this behavior, while legal, could cause all sorts of
> problems on a packet coming back because the SA could end up putting too
> many bytes in the packet.  Does this need to be documented?

The main problem with RADIUS proxies is that they can do whatever they 
want, and it will  not be noticed until its maybe too late. They could 
also remove More-Data-Pending attributes, or the Proxy-State-Len for 
example. They could even re-arrange attributes, or modify their values, 
messing up the entire conversation. But that's not what they are 
expected to do.

Said that, I see the "CHUNK size calculation" mechanism as a best effort 
trade-off, where it improves current solutions (which are none) to 
adjust packet size to the actual limit taking into account proxies 
inclusions.

A worried AS/NAS could lower the guessed value by for example 200-300KB, 
just to make sure that these sort of things are avoided.

>
> 3.  In section 5.1 - Should there be some suggestions about doing retries
> for chucked objects based on a timeout in the case of a proxy dropping it?

Retry policy should be the same as done with non-fragmented packets. The 
NAS will retry a request if no reply arrives in a reasonable time, no 
matter whether it is a "fragmentation" reply or a "standard" reply. 
After a number of retransmissions, the NAS will stop trying, and assume 
the conversation is over. Note that no processing have been performed on 
any side until the whole packet is received (apart of storing the 
received data). Thus, there is no need for a special roll-back mechanism.

>
> 4.  In section 5.3 -- Alan - we had several discussions in Atlanta about the
> interactions of a SAML authorization query combining with an EAP message.  I
> think that we finally decided that since we could fragment the first
> response there were no big issues involved any more.  Is my memory still
> correct on this question?

There's still the situation with SAML queries/requests (or other 
authorization type), which may be larger than the maximum size (though 
not much likely, I think). If a SAML query is required by the AS to 
determine if SAML response must sent or not in the Access-Accept packet, 
it must be definitively sent in an Access-Request packet by the RP, 
along with the  EAP-Message attributes. You would need to perform 
fragmentation if it is too big (note that EAP request may be already 
quite large, so it is not so unlikely).

Of course, another option is to not sending any SAML response data in 
the Access-Accept packet, but some kind notification to the RP in order 
to perform the whole SAML Query/SAML Response exchange *after* 
Access-Accept.

I discussed this alternative with Alan, Josh and Sam, months ago, but 
they argued that this will mandate an additional roundtrip even for RPs 
that are not interested/known nothing about SAML.bv

5.  In section 5.3 - I am not sure why there is a requirement that these
attributes be in the same fragmentation packet.  The server SHOULD NOT start
processing the contents of the sent packet until such a time as entirety of
the full packet has been received, so unless a proxy is going to operate on
these attributes I don't see the point of this.


That's a good question. This came up to me when working with FreeRADIUS 
proxies. FreeRADIUS proxies perform that check (Message-Authenticator 
cannot be without EAP-Message), otherwise the packet is not forwarded. 
Hence, I assumed that this was somehow mandatory.

Now, reviewing RFC 3579 it says that:

    Access-Request packets including EAP-Message attribute(s) without
           a Message-Authenticator attribute SHOULD be silently discarded by
           the RADIUS server.

and:

    Access-Challenge, Access-Accept, or Access-Reject packets
           including EAP-Message attribute(s) without a Message-Authenticator
           attribute SHOULD be silently discarded by the NAS.

I couldn't find any similar text for proxies, so probably you are right 
and I is not necessary.

Anyway, I think the conclusions of the discussion about allowed 
attributes in Access-Challenge packets, specially in conjunction with 
RADIUS-EAP will be relevant here to determine if we can use together 
RADIUS-EAP and RADIUS fragmentation, since we would need to introduce 
this new attributes (More-Data-Pending and Proxy-State-Len) in Challenges.

> 6. In section 5.3 - I think you need to make it explicit that for
> Message-Authenticator, it is the fragment message that will be authenticated
> not the entire unfragmented message.

Probably this will depend on what happens with point 5.

>
> 7.  In section 5.4 - You need to document what happens with the ID attribute
> as well.  (Always last?)

I guess you mean the ID field (not an attribute, I definitively have to 
clarify that)

It will be the last one, but not sure it really matters. I think once 
the RADIUS network layer has processed the packet for retransmissions, 
fragmentation, etc, it does not matter which ID value it has, because it 
should be irrelevant for the attribute processing.

>
> 8.  In section 6.1 - It must not be in Access-Reject packets as well.
> Should that be documented?  (also s/MUST not/MUST NOT/)

Right

>
> 9.  In section 6.2 - see previous comments
>
> 10.  In section 6.3 - the table appears to be wrong.  I think the that
> Proxy-State-Len should be 0 under the Acc column.

When fragmenting an Access-Accept packet, the result transmission of 
chunks is the following: Acc-Cha-Cha-...-Cha-Acc, where the first Acc 
contains the Service-Type=Additional-Authorization, and the last one the 
actual Service-Type.

This first Access-Accept will contain the Proxy-State-Len attribute to 
provide feedback to the RP about the size of Proxy-State attributes.


>
> 11.  In Section 8 - I think there is a potential security consideration that
> may need to be added.  As the system is currently defined, if the
> Message-Authenticator attribute is in the original message, it is not made a
> requirement of all the fragments in the system.  This means that only a
> subset of the original message will be authenticated.  This is a definite
> security change.

Right. See points 5 and 6. Probably Message-Authenticator MUST be 
calculated over the whole packet, not only the subset.

>
> 12.  In section 9 - No IANA actions?  What about the required registrations?

I forgot to fill up that section :). At least we need to define 
More-Data-Pending, Proxy-State-Len and 
Service-Type=Additional-Authorization.

>
> Spelling errors
>
> s/Acess-Request-2/Access-Request-2/
> s/size of he RADIUS/size of the RADIUS/
> s/should they cannot add/should they be unable to add/
> s/how many space/how much space/

Best regards,
Alejandro


>
> jim
>
>


--------------090604040602000905080109
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hello Jim,

    

    thanks for your valuable comments, let me try to answer to some of
    them inline.

    


    

    

      
First, I would like the chairs to issue an adoption call on this document so
we can formally work on it.

Comments on the draft itself.

1.  I just did a count on the number attributes in the example for
Access-Request-1 and came up with a count of 9.  This exceeds the posited
maximum length of 8 that the example is using as a limitation.

    

    

    You counted the ID field, which is represented as an attribute for
    simplicity, though it is not. Prior describing the example it is
    said that

    

      
The Identifier field is denoted as IDX, even though it is
   not an attribute.

    

    I could either change the notation, add a better explanatory
    paragraph or just count it as an attribute for sake of simplicity
    again and say the limit is 9 attributes instead of 8. 

    

    

    

      
2.  In section 5.1 - although this is going to be unusual behavior, a proxy
could remove Proxy-State attributes and keep them for later re-insertion.  I
can imagine that this behavior, while legal, could cause all sorts of
problems on a packet coming back because the SA could end up putting too
many bytes in the packet.  Does this need to be documented?

    

    

    The main problem with RADIUS proxies is that they can do whatever
    they want, and it will  not be noticed until its maybe too late.
    They could also remove More-Data-Pending attributes, or the
    Proxy-State-Len for example. They could even re-arrange attributes,
    or modify their values, messing up the entire conversation. But
    that's not what they are expected to do.

    

    Said that, I see the "CHUNK size calculation" mechanism as a best
    effort trade-off, where it improves current solutions (which are
    none) to adjust packet size to the actual limit taking into account
    proxies inclusions.

    

    A worried AS/NAS could lower the guessed value by for example
    200-300KB, just to make sure that these sort of things are avoided.
    

    

    

      

3.  In section 5.1 - Should there be some suggestions about doing retries
for chucked objects based on a timeout in the case of a proxy dropping it?

    

    

    Retry policy should be the same as done with non-fragmented packets.
    The NAS will retry a request if no reply arrives in a reasonable
    time, no matter whether it is a "fragmentation" reply or a
    "standard" reply. After a number of retransmissions, the NAS will
    stop trying, and assume the conversation is over. Note that no
    processing have been performed on any side until the whole packet is
    received (apart of storing the received data). Thus, there is no
    need for a special roll-back mechanism.

    

    

      

4.  In section 5.3 -- Alan - we had several discussions in Atlanta about the
interactions of a SAML authorization query combining with an EAP message.  I
think that we finally decided that since we could fragment the first
response there were no big issues involved any more.  Is my memory still
correct on this question?

    

    

    There's still the situation with SAML queries/requests (or other
    authorization type), which may be larger than the maximum size
    (though not much likely, I think). If a SAML query is required by
    the AS to determine if SAML response must sent or not in the
    Access-Accept packet, it must be definitively sent in an
    Access-Request packet by the RP, along with the  EAP-Message
    attributes. You would need to perform fragmentation if it is too big
    (note that EAP request may be already quite large, so it is not so
    unlikely).

    

    Of course, another option is to not sending any SAML response data
    in the Access-Accept packet, but some kind notification to the RP in
    order to perform the whole SAML Query/SAML Response exchange *after*
    Access-Accept. 

    

    I discussed this alternative with Alan, Josh and Sam, months ago,
    but they argued that this will mandate an additional roundtrip even
    for RPs that are not interested/known nothing about SAML.bv
    
5.  In section 5.3 - I am not sure why there is a requirement that these
attributes be in the same fragmentation packet.  The server SHOULD NOT start
processing the contents of the sent packet until such a time as entirety of
the full packet has been received, so unless a proxy is going to operate on
these attributes I don't see the point of this.

    

    That's a good question. This came up to me when working with
    FreeRADIUS proxies. FreeRADIUS proxies perform that check
    (Message-Authenticator cannot be without EAP-Message), otherwise the
    packet is not forwarded. Hence, I assumed that this was somehow
    mandatory.

    

    Now, reviewing RFC 3579 it says that:

    

        
Access-Request packets including EAP-Message attribute(s) without
      a Message-Authenticator attribute SHOULD be silently discarded by
      the RADIUS server.

      

    and:
    

        
Access-Challenge, Access-Accept, or Access-Reject packets
      including EAP-Message attribute(s) without a Message-Authenticator
      attribute SHOULD be silently discarded by the NAS.

      

    I couldn't find any similar text for proxies, so probably you are
    right and I is not necessary. 

    

    Anyway, I think the conclusions of the discussion about allowed
    attributes in Access-Challenge packets, specially in conjunction
    with RADIUS-EAP will be relevant here to determine if we can use
    together RADIUS-EAP and RADIUS fragmentation, since we would need to
    introduce this new attributes (More-Data-Pending and
    Proxy-State-Len) in Challenges.

    

    

      
6. In section 5.3 - I think you need to make it explicit that for
Message-Authenticator, it is the fragment message that will be authenticated
not the entire unfragmented message.

    

    

    Probably this will depend on what happens with point 5. 

    

    

      

7.  In section 5.4 - You need to document what happens with the ID attribute
as well.  (Always last?)

    

    

    I guess you mean the ID field (not an attribute, I definitively have
    to clarify that)

    

    It will be the last one, but not sure it really matters. I think
    once the RADIUS network layer has processed the packet for
    retransmissions, fragmentation, etc, it does not matter which ID
    value it has, because it should be irrelevant for the attribute
    processing. 

    

    

      

8.  In section 6.1 - It must not be in Access-Reject packets as well.
Should that be documented?  (also s/MUST not/MUST NOT/)

    

    

    Right

    

    

      

9.  In section 6.2 - see previous comments

10.  In section 6.3 - the table appears to be wrong.  I think the that
Proxy-State-Len should be 0 under the Acc column.

    

    

    When fragmenting an Access-Accept packet, the result transmission of
    chunks is the following: Acc-Cha-Cha-...-Cha-Acc, where the first
    Acc contains the Service-Type=Additional-Authorization, and the last
    one the actual Service-Type. 

    

    This first Access-Accept will contain the Proxy-State-Len attribute
    to provide feedback to the RP about the size of Proxy-State
    attributes.

    

    

    

      

11.  In Section 8 - I think there is a potential security consideration that
may need to be added.  As the system is currently defined, if the
Message-Authenticator attribute is in the original message, it is not made a
requirement of all the fragments in the system.  This means that only a
subset of the original message will be authenticated.  This is a definite
security change.

    

    

    Right. See points 5 and 6. Probably Message-Authenticator MUST be
    calculated over the whole packet, not only the subset.

    

    

      

12.  In section 9 - No IANA actions?  What about the required registrations?

    

    

    I forgot to fill up that section :). At least we need to define
    More-Data-Pending, Proxy-State-Len and
    Service-Type=Additional-Authorization.

    

    

      

Spelling errors

s/Acess-Request-2/Access-Request-2/
s/size of he RADIUS/size of the RADIUS/
s/should they cannot add/should they be unable to add/
s/how many space/how much space/

    

    

    Best regards,

    Alejandro

    

    

    

      

jim




    

    

  


--------------090604040602000905080109--

From ietf@augustcellars.com  Fri Jan 25 09:18:57 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B9D21F8445 for ; Fri, 25 Jan 2013 09:18:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.339
X-Spam-Level: 
X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.259,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yjejPBGskZuS for ; Fri, 25 Jan 2013 09:18:57 -0800 (PST)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED17C21F843E for ; Fri, 25 Jan 2013 09:18:56 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id DFF532CA22; Fri, 25 Jan 2013 09:18:54 -0800 (PST)
From: "Jim Schaad" 
To: "'Alejandro Perez Mendez'" 
References: <005b01cdfa96$d2f173d0$78d45b70$@augustcellars.com> <51024BBA.3020009@um.es>
In-Reply-To: <51024BBA.3020009@um.es>
Date: Fri, 25 Jan 2013 09:18:25 -0800
Message-ID: <009601cdfb20$004a0a70$00de1f50$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01CDFADC.F228ED50"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGLku0lWgd1GMGzAWljYG5o91WzxwEWSsB5mNZlSwA=
Content-Language: en-us
Cc: radext@ietf.org, draft-perez-radext-radius-fragmentation@tools.ietf.org
Subject: Re: [radext] Comments on draft-perez-radext-radius-fragmentation-04
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, 25 Jan 2013 17:18:57 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0097_01CDFADC.F228ED50
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=20

=20

From: Alejandro Perez Mendez [mailto:alex@um.es]=20
Sent: Friday, January 25, 2013 1:09 AM
To: Jim Schaad
Cc: draft-perez-radext-radius-fragmentation@tools.ietf.org; =
radext@ietf.org
Subject: Re: Comments on draft-perez-radext-radius-fragmentation-04

=20

Hello Jim,



=20
3.  In section 5.1 - Should there be some suggestions about doing =
retries
for chucked objects based on a timeout in the case of a proxy dropping =
it?


Retry policy should be the same as done with non-fragmented packets. The =
NAS will retry a request if no reply arrives in a reasonable time, no =
matter whether it is a "fragmentation" reply or a "standard" reply. =
After a number of retransmissions, the NAS will stop trying, and assume =
the conversation is over. Note that no processing have been performed on =
any side until the whole packet is received (apart of storing the =
received data). Thus, there is no need for a special roll-back =
mechanism.



[JLS] Sorry, I should have been more clear on my comment.  Should the =
retry include decreasing the chunk size?

=20
=20
10.  In section 6.3 - the table appears to be wrong.  I think the that
Proxy-State-Len should be 0 under the Acc column.


When fragmenting an Access-Accept packet, the result transmission of =
chunks is the following: Acc-Cha-Cha-...-Cha-Acc, where the first Acc =
contains the Service-Type=3DAdditional-Authorization, and the last one =
the actual Service-Type.=20

This first Access-Accept will contain the Proxy-State-Len attribute to =
provide feedback to the RP about the size of Proxy-State attributes.


[JLS]  This text from section 6.2

   This attribute MAY be present in Access-Challenge packets.  It MUST

   not be included in Access-Accept packets.

=20

=20


Best regards,
Alejandro





=20
=20
jim
=20
=20

=20


------=_NextPart_000_0097_01CDFADC.F228ED50
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


 
 
From: Alejandro Perez Mendez [mailto:alex@um.es] 
Sent: =
Friday, January 25, 2013 1:09 AM
To: Jim Schaad
Cc: =
draft-perez-radext-radius-fragmentation@tools.ietf.org; =
radext@ietf.org
Subject: Re: Comments on =
draft-perez-radext-radius-fragmentation-04
 
Hello =
Jim,

 
3.=C2=A0 In =
section 5.1 - Should there be some suggestions about doing =
retries
for chucked objects based on a timeout in =
the case of a proxy dropping it?

Retry policy should be the same as done with =
non-fragmented packets. The NAS will retry a request if no reply arrives =
in a reasonable time, no matter whether it is a =
"fragmentation" reply or a "standard" reply. After a =
number of retransmissions, the NAS will stop trying, and assume the =
conversation is over. Note that no processing have been performed on any =
side until the whole packet is received (apart of storing the received =
data). Thus, there is no need for a special roll-back =
mechanism.

[JLS] Sorry, I should have been more clear on my comment. =
=C2=A0Should the retry include decreasing the chunk =
size?
 
 
10.=C2=A0 In section 6.3 - the table appears to be =
wrong.=C2=A0 I think the that
Proxy-State-Len =
should be 0 under the Acc column.

When fragmenting an Access-Accept packet, the =
result transmission of chunks is the following: Acc-Cha-Cha-...-Cha-Acc, =
where the first Acc contains the =
Service-Type=3DAdditional-Authorization, and the last one the actual =
Service-Type. 

This first Access-Accept will contain the =
Proxy-State-Len attribute to provide feedback to the RP about the size =
of Proxy-State attributes.


[JLS]=C2=A0 This text from section =
6.2
=C2=A0=C2=A0 This attribute MAY be present in =
Access-Challenge packets.=C2=A0 It MUST
=C2=A0=C2=A0 not be included in Access-Accept =
packets.
 
 

Best =
regards,
Alejandro



 
 
jim
&nb=
sp;
 
 

------=_NextPart_000_0097_01CDFADC.F228ED50--


From alex@um.es  Fri Jan 25 10:21:19 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5820121F843A for ; Fri, 25 Jan 2013 10:21:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 D2t34DHpHu+W for ; Fri, 25 Jan 2013 10:21:18 -0800 (PST)
Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id E11E821F8432 for ; Fri, 25 Jan 2013 10:21:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 8B6545D556 for ; Fri, 25 Jan 2013 19:21:16 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon14.um.es
Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id t1ptpenDFGMl for ; Fri, 25 Jan 2013 19:21:16 +0100 (CET)
Received: from [192.168.1.130] (134.242.14.37.dynamic.jazztel.es [37.14.242.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPSA id B6E415D537 for ; Fri, 25 Jan 2013 19:21:15 +0100 (CET)
Message-ID: <5102CD1A.2050904@um.es>
Date: Fri, 25 Jan 2013 19:21:14 +0100
From: Alejandro Perez Mendez 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: radext@ietf.org
References: <005b01cdfa96$d2f173d0$78d45b70$@augustcellars.com> <51024BBA.3020009@um.es> <009601cdfb20$004a0a70$00de1f50$@augustcellars.com>
In-Reply-To: <009601cdfb20$004a0a70$00de1f50$@augustcellars.com>
Content-Type: multipart/alternative; boundary="------------090202040509040601090608"
Subject: Re: [radext] Comments on draft-perez-radext-radius-fragmentation-04
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, 25 Jan 2013 18:21:19 -0000

This is a multi-part message in MIME format.
--------------090202040509040601090608
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


> *From:*Alejandro Perez Mendez [mailto:alex@um.es]
> *Sent:* Friday, January 25, 2013 1:09 AM
> *To:* Jim Schaad
> *Cc:* draft-perez-radext-radius-fragmentation@tools.ietf.org; 
> radext@ietf.org
> *Subject:* Re: Comments on draft-perez-radext-radius-fragmentation-04
>
> Hello Jim,
>
>   
> 3.  In section 5.1 - Should there be some suggestions about doing retries
> for chucked objects based on a timeout in the case of a proxy dropping it?
>
>
> Retry policy should be the same as done with non-fragmented packets. 
> The NAS will retry a request if no reply arrives in a reasonable time, 
> no matter whether it is a "fragmentation" reply or a "standard" reply. 
> After a number of retransmissions, the NAS will stop trying, and 
> assume the conversation is over. Note that no processing have been 
> performed on any side until the whole packet is received (apart of 
> storing the received data). Thus, there is no need for a special 
> roll-back mechanism.
>
> [JLS] Sorry, I should have been more clear on my comment.  Should the 
> retry include decreasing the chunk size?
>

That could be more difficult from an implementation point of view 
(though doable, of course). In our implementation, fragmentation layer 
provides the CHUNK to the "network delivery" layer, which is the one 
performing the retransmissions. It knows nothing about fragmentation. 
But, of course, it is an implementation aspect and it can be done 
differently. RP start with a small size of CHUNK, and it should be 
conservative on the chosen size to avoid incurring in proxies dropping 
packets.

>   
>   
> 10.  In section 6.3 - the table appears to be wrong.  I think the that
> Proxy-State-Len should be 0 under the Acc column.
>
>
> When fragmenting an Access-Accept packet, the result transmission of 
> chunks is the following: Acc-Cha-Cha-...-Cha-Acc, where the first Acc 
> contains the Service-Type=Additional-Authorization, and the last one 
> the actual Service-Type.
>
> This first Access-Accept will contain the Proxy-State-Len attribute to 
> provide feedback to the RP about the size of Proxy-State attributes.
>
>
> [JLS]  This text from section 6.2
>
>    This attribute MAY be present in Access-Challenge packets.  It MUST
>
>    not be included in Access-Accept packets.
>

Oh, that text its incorrect. Thanks!

>   
>
>
> Best regards,
> Alejandro
>
>
>
>   
>   
> jim
>   
>   
>
>
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext


--------------090202040509040601090608
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    

      
      
      
      

        
 

        
 

        

          

            

              
From:
                  Alejandro Perez Mendez [mailto:alex@um.es] 

                  Sent: Friday, January 25, 2013 1:09 AM

                  To: Jim Schaad

                  Cc:
                  draft-perez-radext-radius-fragmentation@tools.ietf.org;
                  radext@ietf.org

                  Subject: Re: Comments on
                  draft-perez-radext-radius-fragmentation-04

            

          

          
 

          
Hello Jim,

            

            

          
 

          
3.  In section 5.1 - Should there be some suggestions about doing retries

          
for chucked objects based on a timeout in the case of a proxy dropping it?

          


            Retry policy should be the same as done with non-fragmented
            packets. The NAS will retry a request if no reply arrives in
            a reasonable time, no matter whether it is a "fragmentation"
            reply or a "standard" reply. After a number of
            retransmissions, the NAS will stop trying, and assume the
            conversation is over. Note that no processing have been
            performed on any side until the whole packet is received
            (apart of storing the received data). Thus, there is no need
            for a special roll-back mechanism.

            

            

          
[JLS]
              Sorry, I should have been more clear on my comment.
               Should the retry include decreasing the chunk size?

        

      

    

    

    That could be more difficult from an implementation point of view
    (though doable, of course). In our implementation, fragmentation
    layer provides the CHUNK to the "network delivery" layer, which is
    the one performing the retransmissions. It knows nothing about
    fragmentation. But, of course, it is an implementation aspect and it
    can be done differently. RP start with a small size of CHUNK, and it
    should be conservative on the chosen size to avoid incurring in
    proxies dropping packets.

    

    

      

        

          

          
 

          
 

          
10.  In section 6.3 - the table appears to be wrong.  I think the that

          
Proxy-State-Len should be 0 under the Acc column.

          


            When fragmenting an Access-Accept packet, the result
            transmission of chunks is the following:
            Acc-Cha-Cha-...-Cha-Acc, where the first Acc contains the
            Service-Type=Additional-Authorization, and the last one the
            actual Service-Type. 

            

            This first Access-Accept will contain the Proxy-State-Len
            attribute to provide feedback to the RP about the size of
            Proxy-State attributes.

            

            

            [JLS]  This text from section
              6.2

          
   This attribute MAY be
              present in Access-Challenge packets.  It MUST

          
   not be included in
              Access-Accept packets.

        

      

    

    

    Oh, that text its incorrect. Thanks!

    

    

      

        

          

          
 

          
 

          


            Best regards,

            Alejandro

            

            

            

            

          
 

          
 

          
jim

          
 

          
 

          
 

        

      

      

      

      

      
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext


    

    

  


--------------090202040509040601090608--

From aland@deployingradius.com  Mon Jan 28 07:38:26 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B274521F87C3 for ; Mon, 28 Jan 2013 07:38:26 -0800 (PST)
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 EzkPs2gSsiue for ; Mon, 28 Jan 2013 07:38:26 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 343C721F8573 for ; Mon, 28 Jan 2013 07:38:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id DAF15224114B for ; Mon, 28 Jan 2013 16:37:24 +0100 (CET)
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 n5pB3FabskWm for ; Mon, 28 Jan 2013 16:37:22 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id ACD3C22409EF for ; Mon, 28 Jan 2013 16:37:22 +0100 (CET)
Message-ID: <51069B31.8010003@deployingradius.com>
Date: Mon, 28 Jan 2013 10:37:21 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: "radext@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [radext] DTLS document
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, 28 Jan 2013 15:38:26 -0000

  This has expired, sorry.  I've been out of commission the last week or
so.  I should have a final update this week.

  Alan DeKok.

From internet-drafts@ietf.org  Mon Jan 28 07:45:20 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D4421F8901; Mon, 28 Jan 2013 07:45:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level: 
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 G2xZtL3ZPBl7; Mon, 28 Jan 2013 07:45:15 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA8A21F892C; Mon, 28 Jan 2013 07:45:14 -0800 (PST)
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.37
Message-ID: <20130128154514.27060.38071.idtracker@ietfa.amsl.com>
Date: Mon, 28 Jan 2013 07:45:14 -0800
Cc: radext@ietf.org
Subject: [radext] I-D Action: draft-ietf-radext-radius-extensions-09.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, 28 Jan 2013 15:45:20 -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           : Remote Authentication Dial In User Service (RADIUS) Prot=
ocol Extensions
	Author(s)       : Alan DeKok
                          Avi Lior
	Filename        : draft-ietf-radext-radius-extensions-09.txt
	Pages           : 67
	Date            : 2013-01-28

Abstract:
   The Remote Authentication Dial In User Service (RADIUS) protocol is
   nearing exhaustion of its current 8-bit Attribute Type space.  In
   addition, experience shows a growing need for complex grouping, along
   with attributes which can carry more than 253 octets of data.  This
   document defines changes to RADIUS which address all of the above
   problems.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-radext-radius-extensions-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-radius-extensions-09


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Mon Jan 28 07:50:31 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D290B21F845A; Mon, 28 Jan 2013 07:50:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 Rwz7oFB+ntAF; Mon, 28 Jan 2013 07:50:31 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B7521F87E0; Mon, 28 Jan 2013 07:50:31 -0800 (PST)
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.37
Message-ID: <20130128155031.8392.45953.idtracker@ietfa.amsl.com>
Date: Mon, 28 Jan 2013 07:50:31 -0800
Cc: radext@ietf.org
Subject: [radext] I-D Action: draft-ietf-radext-nai-02.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, 28 Jan 2013 15:50:32 -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           : The Network Access Identifier
	Author(s)       : Alan DeKok
	Filename        : draft-ietf-radext-nai-02.txt
	Pages           : 22
	Date            : 2013-01-28

Abstract:
   In order to provide inter-domain authentication services, it is
   necessary to have a standardized method that domains can use to
   identify each others users.  This document defines the syntax for the
   Network Access Identifier (NAI), the user identity submitted by the
   client prior to accessing network resources. This document is a
   revised version of RFC 4282 [RFC4282], which addresses issues with
   international character sets, as well as a number of other
   corrections to the previous document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-radext-nai

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-radext-nai-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-nai-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From trac+radext@trac.tools.ietf.org  Mon Jan 28 10:42:38 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD30321F86E4 for ; Mon, 28 Jan 2013 10:42:38 -0800 (PST)
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 JbQ39EmbeL-N for ; Mon, 28 Jan 2013 10:42:38 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E644B21F86D8 for ; Mon, 28 Jan 2013 10:42:37 -0800 (PST)
Received: from localhost ([127.0.0.1]:51408 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tztf2-0008Lu-9O; Mon, 28 Jan 2013 19:42:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "radext issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-radext-dtls@tools.ietf.org, aland@deployingradius.com
X-Trac-Project: radext
Date: Mon, 28 Jan 2013 18:42:28 -0000
X-URL: http://tools.ietf.org/radext/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/136#comment:1
Message-ID: <074.080ea6fc9d1dcb3d0719e6b9bf88e576@trac.tools.ietf.org>
References: <059.d793aee480c4d789a537efce305ec9f7@trac.tools.ietf.org>
X-Trac-Ticket-ID: 136
In-Reply-To: <059.d793aee480c4d789a537efce305ec9f7@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@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@freeradius.org
Resent-Message-Id: <20130128184237.E644B21F86D8@ietfa.amsl.com>
Resent-Date: Mon, 28 Jan 2013 10:42:37 -0800 (PST)
Resent-From: trac+radext@trac.tools.ietf.org
Cc: radext@ietf.org
Subject: Re: [radext] #136: Table state management as security consideration?
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, 28 Jan 2013 18:42:38 -0000

#136: Table state management as security consideration?


Comment (by aland@deployingradius.com):

 I'm not sure how else to tie DTLS packet -> DTLS session.  The 4-tuple of
 src/dst IP/port seems pretty definitive.

 I'll add a note to 4.1 saying that other methods are possible.

 Can DTLS packets for one session arrive from *different* source ports?
 i.e. packet 1 from port A, packet 2 from port B.  If so, then the tracking
 method should be described here.  There are also security considerations
 which may apply.

 If all packets for a session match one 4-tuple, then the text seems fine
 as-is.

 The security policy is tracked in the entry for each 4-tuple.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-radext-
  ncamwing@cisco.com     |  dtls@tools.ietf.org
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  dtls         |     Version:
 Severity:  -            |  Resolution:
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
radext 


From trac+radext@trac.tools.ietf.org  Mon Jan 28 10:46:04 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E2321F8722 for ; Mon, 28 Jan 2013 10:46:01 -0800 (PST)
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 pBXi9dU-hp50 for ; Mon, 28 Jan 2013 10:46:00 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEA921F86E4 for ; Mon, 28 Jan 2013 10:46:00 -0800 (PST)
Received: from localhost ([127.0.0.1]:51693 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TztiQ-00042M-Hc; Mon, 28 Jan 2013 19:45:58 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "radext issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-radext-dtls@tools.ietf.org, aland@deployingradius.com
X-Trac-Project: radext
Date: Mon, 28 Jan 2013 18:45:58 -0000
X-URL: http://tools.ietf.org/radext/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/135#comment:1
Message-ID: <074.b2b4c2d60dd4e64206affa8997ef25f6@trac.tools.ietf.org>
References: <059.18713e29caaa8e0bdab2aacfee526283@trac.tools.ietf.org>
X-Trac-Ticket-ID: 135
In-Reply-To: <059.18713e29caaa8e0bdab2aacfee526283@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@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@freeradius.org
Resent-Message-Id: <20130128184600.6FEA921F86E4@ietfa.amsl.com>
Resent-Date: Mon, 28 Jan 2013 10:46:00 -0800 (PST)
Resent-From: trac+radext@trac.tools.ietf.org
Cc: radext@ietf.org
Subject: Re: [radext] #135: Server policy handling should be informative
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, 28 Jan 2013 18:46:05 -0000

#135: Server policy handling should be informative

Changes (by aland@deployingradius.com):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 I'm not sure what is meant here.  In order for transition to happen, each
 server needs to track whether or not the client has performed DTLS.  This
 section documents that, along with the administrative policy for migrating
 to DTLS.

 So the text seems to address these concerns already.

 I don't see how else a server can track DTLS.  If there's an
 administrative policy, it has to be represented as a flag related to
 "DTLS".  That's what this section does.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-radext-
  ncamwing@cisco.com     |  dtls@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:
Component:  dtls         |     Version:
 Severity:  -            |  Resolution:  wontfix
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
radext 


From trac+radext@trac.tools.ietf.org  Mon Jan 28 11:01:39 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73F021F879A for ; Mon, 28 Jan 2013 11:01:38 -0800 (PST)
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 P5Y0L4AMKPhh for ; Mon, 28 Jan 2013 11:01:37 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 67D3421F8786 for ; Mon, 28 Jan 2013 11:01:36 -0800 (PST)
Received: from localhost ([127.0.0.1]:52964 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TztxW-0004TQ-Fa; Mon, 28 Jan 2013 20:01:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "radext issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-radext-dtls@tools.ietf.org, aland@deployingradius.com
X-Trac-Project: radext
Date: Mon, 28 Jan 2013 19:01:34 -0000
X-URL: http://tools.ietf.org/radext/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/141#comment:2
Message-ID: <074.6fe0c6ba22f5035826d78628ec5e6f35@trac.tools.ietf.org>
References: <059.d403121a5ea392593c0e3b1e9c21df0a@trac.tools.ietf.org>
X-Trac-Ticket-ID: 141
In-Reply-To: <059.d403121a5ea392593c0e3b1e9c21df0a@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@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@freeradius.org
Resent-Message-Id: <20130128190136.67D3421F8786@ietfa.amsl.com>
Resent-Date: Mon, 28 Jan 2013 11:01:36 -0800 (PST)
Resent-From: trac+radext@trac.tools.ietf.org
Cc: radext@ietf.org
Subject: Re: [radext] #141: Comments on Section 4.2
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, 28 Jan 2013 19:01:39 -0000

#141: Comments on Section 4.2

Changes (by aland@deployingradius.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Updated the doc.  New rev shortly.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-radext-
  jsalowey@cisco.com     |  dtls@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:  milestone1
Component:  dtls         |     Version:  1.0
 Severity:  In WG Last   |  Resolution:  fixed
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
radext 


From trac+radext@trac.tools.ietf.org  Mon Jan 28 11:03:03 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9B721F8718 for ; Mon, 28 Jan 2013 11:03:03 -0800 (PST)
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 5eWdCLGLULw8 for ; Mon, 28 Jan 2013 11:03:02 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3489521F8425 for ; Mon, 28 Jan 2013 11:03:02 -0800 (PST)
Received: from localhost ([127.0.0.1]:53210 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tztyv-0008VT-1s; Mon, 28 Jan 2013 20:03:01 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "radext issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-radext-dtls@tools.ietf.org, aland@deployingradius.com
X-Trac-Project: radext
Date: Mon, 28 Jan 2013 19:03:01 -0000
X-URL: http://tools.ietf.org/radext/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/134#comment:1
Message-ID: <074.aa12f681cabf6b07a876843f1ae54e2c@trac.tools.ietf.org>
References: <059.262988ca8173de818e62ac830cb12bd1@trac.tools.ietf.org>
X-Trac-Ticket-ID: 134
In-Reply-To: <059.262988ca8173de818e62ac830cb12bd1@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@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@freeradius.org
Resent-Message-Id: <20130128190302.3489521F8425@ietfa.amsl.com>
Resent-Date: Mon, 28 Jan 2013 11:03:02 -0800 (PST)
Resent-From: trac+radext@trac.tools.ietf.org
Cc: radext@ietf.org
Subject: Re: [radext] #134: Editorial nits on radext-dtls-02
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, 28 Jan 2013 19:03:03 -0000

#134: Editorial nits on radext-dtls-02

Changes (by aland@deployingradius.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 fixed.  new rev shortly.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-radext-
  ncamwing@cisco.com     |  dtls@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  minor        |   Milestone:
Component:  dtls         |     Version:
 Severity:  -            |  Resolution:  fixed
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
radext 


From trac+radext@trac.tools.ietf.org  Mon Jan 28 11:13:09 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450A321F85B2 for ; Mon, 28 Jan 2013 11:13:09 -0800 (PST)
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 ldqnU+nst4S3 for ; Mon, 28 Jan 2013 11:13:07 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 00CFE21F8689 for ; Mon, 28 Jan 2013 11:13:06 -0800 (PST)
Received: from localhost ([127.0.0.1]:53777 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tzu8d-0005MM-PG; Mon, 28 Jan 2013 20:13:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "radext issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: aland@deployingradius.com, bernard_aboba@hotmail.com
X-Trac-Project: radext
Date: Mon, 28 Jan 2013 19:13:03 -0000
X-URL: http://tools.ietf.org/radext/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/65#comment:3
Message-ID: <079.39f6db4c40045cb5faed6cf88aaab82a@trac.tools.ietf.org>
References: <064.b5fbc75965f33629034d4be3708706fb@trac.tools.ietf.org>
X-Trac-Ticket-ID: 65
In-Reply-To: <064.b5fbc75965f33629034d4be3708706fb@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: aland@deployingradius.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] #65: Multiple dtls sessions in a tuple?
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, 28 Jan 2013 19:13:09 -0000

#65: Multiple dtls sessions in a tuple?


Comment (by aland@deployingradius.com):

 Added text:

-- 
----------------------------------+----------------------------------------
 Reporter:  peterd@iea-           |       Owner:  aland@deployingradius.com
  software.com                    |      Status:  assigned
     Type:  enhancement           |   Milestone:  milestone1
 Priority:  trivial               |     Version:  1.0
Component:  dtls                  |  Resolution:
 Severity:  Active WG Document    |
 Keywords:                        |
----------------------------------+----------------------------------------

Ticket URL: 
radext 


From trac+radext@trac.tools.ietf.org  Mon Jan 28 11:13:27 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD08621F8689 for ; Mon, 28 Jan 2013 11:13:27 -0800 (PST)
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 6odrkqqo9Kha for ; Mon, 28 Jan 2013 11:13:27 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D735921F85B2 for ; Mon, 28 Jan 2013 11:13:26 -0800 (PST)
Received: from localhost ([127.0.0.1]:53846 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tzu8z-0002Js-Qe; Mon, 28 Jan 2013 20:13:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "radext issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: aland@deployingradius.com, bernard_aboba@hotmail.com
X-Trac-Project: radext
Date: Mon, 28 Jan 2013 19:13:25 -0000
X-URL: http://tools.ietf.org/radext/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/65#comment:4
Message-ID: <079.ec9e52ad77394ceea39e05233f9b2cbb@trac.tools.ietf.org>
References: <064.b5fbc75965f33629034d4be3708706fb@trac.tools.ietf.org>
X-Trac-Ticket-ID: 65
In-Reply-To: <064.b5fbc75965f33629034d4be3708706fb@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: aland@deployingradius.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] #65: Multiple dtls sessions in a tuple?
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, 28 Jan 2013 19:13:27 -0000

#65: Multiple dtls sessions in a tuple?

Changes (by aland@deployingradius.com):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 Added text:

 Since UDP is stateless, the potential exists for the client to
 initiate a new DTLS session using a particular 4-tuple, before the
 server has closed the old session.  For security reasons, the server
 must keep the old session active until it has received secure
 notification from the client that the session is closed.  Or, when the
 server has decided for itself that the session is closed.  Taking any
 other action would permit unauthenticated clients to perform a DoS
 attack, by closing active DTLS session.

 As a result, servers MUST ignore any attempts to re-use an existing
 4-tuple from an active session.  This requirement can likely be
 reached by simply processing the packet through the existing session,
 as with any other packet received via that 4-tuple.  Non-compliant, or
 unexpected packets will be ignored by the SSL layer.

 The above requirement is mitigated by the suggestion in Section 6.1,
 below, that the client use a local proxy for all RADIUS traffic.  That
 proxy can then track the ports which it uses, and ensure that re-use
 of 4-tuples is avoided.  The exact process by which this tracking is
 done is outside of the scope of this document.

-- 
----------------------------------+----------------------------------------
 Reporter:  peterd@iea-           |       Owner:  aland@deployingradius.com
  software.com                    |      Status:  closed
     Type:  enhancement           |   Milestone:  milestone1
 Priority:  trivial               |     Version:  1.0
Component:  dtls                  |  Resolution:  fixed
 Severity:  Active WG Document    |
 Keywords:                        |
----------------------------------+----------------------------------------

Ticket URL: 
radext 


From trac+radext@trac.tools.ietf.org  Mon Jan 28 12:57:12 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F5E21F84FB for ; Mon, 28 Jan 2013 12:57:12 -0800 (PST)
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 qpOEjz+AHIrO for ; Mon, 28 Jan 2013 12:57:12 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E355C21F84F3 for ; Mon, 28 Jan 2013 12:57:10 -0800 (PST)
Received: from localhost ([127.0.0.1]:60080 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TzvlI-0004Li-0l; Mon, 28 Jan 2013 21:57:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "radext issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-radext-dtls@tools.ietf.org, aland@deployingradius.com
X-Trac-Project: radext
Date: Mon, 28 Jan 2013 20:57:03 -0000
X-URL: http://tools.ietf.org/radext/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/138#comment:1
Message-ID: <074.ba88a437cd78b14d7b748134e45f107b@trac.tools.ietf.org>
References: <059.d09147c3ec8e9a49d033b446fa28cd0c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 138
In-Reply-To: <059.d09147c3ec8e9a49d033b446fa28cd0c@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@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@freeradius.org
Resent-Message-Id: <20130128205710.E355C21F84F3@ietfa.amsl.com>
Resent-Date: Mon, 28 Jan 2013 12:57:10 -0800 (PST)
Resent-From: trac+radext@trac.tools.ietf.org
Cc: radext@ietf.org
Subject: Re: [radext] #138: The sections referenced in the RADIUS/TLS RFC in section 2.2.1 are wrong.
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, 28 Jan 2013 20:57:13 -0000

#138: The sections referenced in the RADIUS/TLS RFC in section 2.2.1 are wrong.

Changes (by aland@deployingradius.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 fixed.  A new rev will be issued shortly.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-radext-
  jsalowey@cisco.com     |  dtls@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:  milestone1
Component:  dtls         |     Version:  1.0
 Severity:  In WG Last   |  Resolution:  fixed
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
radext 


From internet-drafts@ietf.org  Mon Jan 28 13:04:45 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E0A21F87C3; Mon, 28 Jan 2013 13:04:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.522
X-Spam-Level: 
X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 PzFJimwIrB3D; Mon, 28 Jan 2013 13:04:44 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D7A21F8715; Mon, 28 Jan 2013 13:04:44 -0800 (PST)
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.37
Message-ID: <20130128210444.8132.21837.idtracker@ietfa.amsl.com>
Date: Mon, 28 Jan 2013 13:04:44 -0800
Cc: radext@ietf.org
Subject: [radext] I-D Action: draft-ietf-radext-dtls-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, 28 Jan 2013 21:04:45 -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           : DTLS as a Transport Layer for RADIUS
	Author(s)       : Alan DeKok
	Filename        : draft-ietf-radext-dtls-03.txt
	Pages           : 23
	Date            : 2013-01-28

Abstract:
   The RADIUS protocol [RFC2865] has limited support for authentication
   and encryption of RADIUS packets.  The protocol transports data "in
   the clear", although some parts of the packets can have "obfuscated"
   content.  Packets may be replayed verbatim by an attacker, and
   client-server authentication is based on fixed shared secrets.  This
   document specifies how the Datagram Transport Layer Security (DTLS)
   protocol may be used as a fix for these problems.  It also describes
   how implementations of this proposal can co-exist with current RADIUS
   systems.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-radext-dtls

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-radext-dtls-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dtls-03


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From rafa@um.es  Tue Jan 29 08:05:31 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A7C21F8936; Tue, 29 Jan 2013 08:05:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 sgyf9M0PPq9m; Tue, 29 Jan 2013 08:05:30 -0800 (PST)
Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id DD2DA21F890F; Tue, 29 Jan 2013 08:05:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 697CE53657; Tue, 29 Jan 2013 17:05:21 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon11.um.es
Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hgXQB-2okM9u; Tue, 29 Jan 2013 17:05:21 +0100 (CET)
Received: from inf-205-80.inf.um.es (inf-205-80.inf.um.es [155.54.205.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPSA id 8C144536D6; Tue, 29 Jan 2013 17:05:19 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1283)
From: Rafa Marin Lopez 
In-Reply-To: <5101047D.20103@um.es>
Date: Tue, 29 Jan 2013 17:05:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es>
References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es>
To: radext@ietf.org, abfab@ietf.org
X-Mailer: Apple Mail (2.1283)
Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 29 Jan 2013 16:05:31 -0000

Dear all,

we have received additional comments from Yoshihiro Ohba (many thanks) =
that we share with you.=20

Please, see some comments inline.

"Here is my review of draft-perez-radext-radius-fragmentation-04.

Section 1:

"Each RADIUS packet can transport several RADIUS attributes, to convey
the necessary information to the other peer, up to a maximum size of 4
KB of total data (including RADIUS packet headers)."

[YO] I suggest to replace "4 KB" with "4096 bytes" throughout the
document since "KB" can mean 4000 bytes in some cases.

[Rafa] OK.


"A reference-based mechanism is also proposed in [RFC6158], where
attributes can be obtained through an out-of-band protocol."

[YO} Meaning of this sentence is unclear. Does this mean RADIUS
attributes are obtained through some other protocol instead of RADIUS?
Or does this mean the actual format of the Value field of a RADIUS
Attribute is defined in other protocol specification? In the latter
case, it should be also mentioned that RADIUS-EAP is categorized as the
mechanism defined in RFC 6158.

[Rafa] It is referring the value of the attributes can be obtained by =
other protocol instead of RADIUS. This is coming from a previous comment =
related with SAML transport. Instead of transporting the real SAML =
messages an URL is set as attribute value. We can try to clarify a =
little bit more.

"However, there are no proposals to deal with fragmentation at a packet
level, when the total size exceeds the 4 KB limit imposed by the RADIUS
specification."

[YO] Meaning of "at a packet level" is unclear. Suggested change:
"However, there are no proposals to fragement a large-sized RADIUS
packet into multiple small-sized RADIUS packets, where the length of the
original (unfragmented) RADIUS packet exceeds the 4096-octet limit
imposed by the RADIUS specification."

[Rafa] This sounds good.


Section 2:

[YO] I am not sure if "T" flag is needed. In other words, it should be
possible to change [I-D.ietf-radext-radius-extensions] to simply allow a
fragment with the M-flag cleared not to be included in a non-last chunk.

[Rafa]=20

Yes, that may be possible. It is worth noting that we wanted to keep =
unmodified any existing I-D by the time being. Moreover, =
[I-D.ietf-radext-radius-extensions] has not considered that =
fragmentation at packet level may occur for obvious reasons. Moreover, =
that I-D is in a mature state now.

In any case, we may ask authors of [I-D.ietf-radext-radius-extensions].

Section 3.3:

[YO] Access-Accept fragmentation scheme looks odd compared to
Access-Request and Access-Challenge fragmentation schemes. There are
several questions related to this: (1) Why multiple chunks of
Access-Accept cannot be sent without having an Access-Challange to be
sent in between? (2) Why an Access-Accept cannot contain a
More-Data-Pending attribute instead of using a new service type value?
(3) How can a large attributue that is allowed to appear in an
Access-Accept but not allowed to appear in Access-Challenge be =
fragmented?

[Rafa]

1) We wanted to be symmetric in the design, where =
Access-Request/Access-Challenge exchange is used somehow for =
fragmentation support. In any case, we have also considered the usage of =
Access-Accept with Service-Type[AddAuth] so until all the attributes in =
the whole RADIUS Access-Accept are finally sent the exchange will be =
Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one =
is simply Access-Request/Access-Accept. This mode of operation would =
solve your question 3).

2) I think that may be also possible. In any case, I think Alan or Alex =
can elaborate a little bit a more about the usage of =
Service-Type[AddAuth].

3) Precisely, trying to answer this question we just came up with the =
solution in 1). What do you think? =20

Section 8:

[YO] Security Considerations section is too short. Security mechansims
that are needed for secure operation of the proposed fragmentation
mechanism needs to be described in this section.

[Rafa] Yes this section will be improved. Jim also raised comments about =
it.

Section 9:

[YO] I don't think the following statement is true: "This document has
no actions for IANA." because Section 6 defines new attributes.

[Rafa] Correct. This needs to be fixed.

Best Regards,
Yoshihiro Ohba
"

Best regards.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------





From rafa@um.es  Tue Jan 29 08:18:08 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E574B21F8801 for ; Tue, 29 Jan 2013 08:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 5-1Lp2frkydE for ; Tue, 29 Jan 2013 08:18:08 -0800 (PST)
Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 4228A21F87DC for ; Tue, 29 Jan 2013 08:18:08 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id E64B84BE9C; Tue, 29 Jan 2013 17:18:06 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon12.um.es
Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 61hYUCnx5yqt; Tue, 29 Jan 2013 17:18:06 +0100 (CET)
Received: from inf-205-80.inf.um.es (inf-205-80.inf.um.es [155.54.205.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPSA id 0B5454BEBF; Tue, 29 Jan 2013 17:18:04 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Rafa Marin Lopez 
In-Reply-To: <51024BBA.3020009@um.es>
Date: Tue, 29 Jan 2013 17:18:03 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7759873F-EEEB-42B6-AE99-098433F96C39@um.es>
References: <005b01cdfa96$d2f173d0$78d45b70$@augustcellars.com> <51024BBA.3020009@um.es>
To: radext@ietf.org
X-Mailer: Apple Mail (2.1283)
Cc: draft-perez-radext-radius-fragmentation@tools.ietf.org
Subject: Re: [radext] Comments on draft-perez-radext-radius-fragmentation-04
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, 29 Jan 2013 16:18:09 -0000

Hi Jim , Alex:

> 5.  In section 5.3 - I am not sure why there is a requirement that =
these
> attributes be in the same fragmentation packet.  The server SHOULD NOT =
start
> processing the contents of the sent packet until such a time as =
entirety of
> the full packet has been received, so unless a proxy is going to =
operate on
> these attributes I don't see the point of this.
I agree that maybe section 5.3 is too much restrictive taking into =
account the text that Alex pasted from RFC 3579

>> 11.  In Section 8 - I think there is a potential security =
consideration that
>> may need to be added.  As the system is currently defined, if the
>> Message-Authenticator attribute is in the original message, it is not =
made a
>> requirement of all the fragments in the system.  This means that only =
a
>> subset of the original message will be authenticated.  This is a =
definite
>> security change.
>=20
> Right. See points 5 and 6. Probably Message-Authenticator MUST be =
calculated over the whole packet, not only the subset.

Message-Authenticator is a hop-by-hop authenticator so I do not think it =
can be calculated over the whole packet. One alternative is just =
describing what Jim proposes by adding some note to security =
considerations. Other alternative might be to include =
Message-Authenticator attribute in all chunks from the one which =
requires it. For example if a RADIUS Access-Accept carries an =
EAP-Success and a set of attributes that do not fit in the packet, =
Message-Authenticator is included in that RADIUS Access-Accept and in =
all chunks from that message until all chunks have been sent.=20

What do you think?


Best regards.
>> jim
>>=20
>>=20
>=20
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------





From diego@tid.es  Tue Jan 29 13:03:57 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C0421F8816 for ; Tue, 29 Jan 2013 13:03:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.469
X-Spam-Level: 
X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[AWL=1.131,  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 H5Eltnw5W5tE for ; Tue, 29 Jan 2013 13:03:57 -0800 (PST)
Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2F421F880B for ; Tue, 29 Jan 2013 13:03:56 -0800 (PST)
Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MHE00GXTNUIJL@tid.hi.inet> for radext@ietf.org; Tue, 29 Jan 2013 22:03:54 +0100 (MET)
Received: from vanvan (vanvan.hi.inet [10.95.78.49])	by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 56.36.02896.A3938015; Tue, 29 Jan 2013 22:03:54 +0100 (CET)
Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MHE00I3HNUHYO@tid.hi.inet> for radext@ietf.org; Tue, 29 Jan 2013 22:03:53 +0100 (MET)
Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0328.009; Tue, 29 Jan 2013 22:03:53 +0100
Date: Tue, 29 Jan 2013 21:03:53 +0000
From: "Diego R. Lopez" 
In-reply-to: <7759873F-EEEB-42B6-AE99-098433F96C39@um.es>
X-Originating-IP: [10.95.64.115]
To: Rafa Marin Lopez 
Message-id: 
Content-id: <08984B78D19575469A06725A48A910F3@hi.inet>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: base64
Accept-Language: en-US
Thread-topic: [radext] Comments on draft-perez-radext-radius-fragmentation-04
Thread-index: Ac36gVony5sg1ydWRv+ksunU9EeNsAAUelEAANgkVoAACftmAA==
X-AuditID: 0a5f4e69-b7f636d000000b50-38-5108393ad7be
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsXCFe9nqGtlyRFoMG+GkEXLq5lsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuHD9I1PBHdGKV40zWRsYp4h2MXJySAiYSCxveMYIYYtJXLi3 nq2LkYtDSGAbo8TGaU0sIAkhgZ+MEm+OVEMkZjJK3G/bC5ZgEVCV6Px3iQnEZgOyHzX/Zgex hQV8JO6vmA1mcwpYShy68YEVYoOCxJ9zj8F6RQQUJbb8a2cDsZkFFjFK3P2jDGLzCnhLXD13 lh0ibiax/O4/doi4oMSPyfeAejmA4uoSU6bkQpSISzS33mSBsBUlpi1qAHuGEeiZ76fWMEGs 8pVonNXCCGE7Say+ADFSQkBAYsme88wQtqjEy8f/WCF+bGeUWLHjL/MERolZSM6YheSMWQhn zEJyxiwkZyxgZF3FKFacVJSZnlGSm5iZk25gpJeRqZeZl1qyiRESdZk7GJfvVDnEKMDBqMTD ++Eaa6AQa2JZcWXuIUZJDiYlUd5kM45AIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8CmpAOd6U xMqq1KJ8mJQMB4eSBK+HBVBKsCg1PbUiLTMHmFpg0kwcnCDtPEDt+SA1vMUFibnFmekQ+VOM klLivFYgCQGQREZpHlzvK0ZxoCOFeYNBsjzAJAjX9QpoIBPQQKM2dpCBJYkIKakGRm/jlQEl f77zztv/VnJTQqJxfFZT5cQzGSmb+Th/tFX9eM1x45qRrbApa87ra4lpG2a84fy0sN+tIGuz ucm0MzZer5+oil84paC/lLW+WLLwmOjbbyodm03E1lktDdPfP/v89CfN5pFHNZ/IBQmGvOdq ULL8dHHinO6juo5OX7Y9/cc9bZlijRJLcUaioRZzUXEiAP9CKMM/AwAA
References: <005b01cdfa96$d2f173d0$78d45b70$@augustcellars.com> <51024BBA.3020009@um.es> <7759873F-EEEB-42B6-AE99-098433F96C39@um.es>
Cc: "" , "" 
Subject: Re: [radext] Comments on draft-perez-radext-radius-fragmentation-04
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, 29 Jan 2013 21:03:57 -0000

SGksDQoNCk9uIDI5IEphbiAyMDEzLCBhdCAxNzoxOCAsIFJhZmEgTWFyaW4gTG9wZXogd3JvdGU6
DQo+Pj4gMTEuICBJbiBTZWN0aW9uIDggLSBJIHRoaW5rIHRoZXJlIGlzIGEgcG90ZW50aWFsIHNl
Y3VyaXR5IGNvbnNpZGVyYXRpb24gdGhhdA0KPj4+IG1heSBuZWVkIHRvIGJlIGFkZGVkLiAgQXMg
dGhlIHN5c3RlbSBpcyBjdXJyZW50bHkgZGVmaW5lZCwgaWYgdGhlDQo+Pj4gTWVzc2FnZS1BdXRo
ZW50aWNhdG9yIGF0dHJpYnV0ZSBpcyBpbiB0aGUgb3JpZ2luYWwgbWVzc2FnZSwgaXQgaXMgbm90
IG1hZGUgYQ0KPj4+IHJlcXVpcmVtZW50IG9mIGFsbCB0aGUgZnJhZ21lbnRzIGluIHRoZSBzeXN0
ZW0uICBUaGlzIG1lYW5zIHRoYXQgb25seSBhDQo+Pj4gc3Vic2V0IG9mIHRoZSBvcmlnaW5hbCBt
ZXNzYWdlIHdpbGwgYmUgYXV0aGVudGljYXRlZC4gIFRoaXMgaXMgYSBkZWZpbml0ZQ0KPj4+IHNl
Y3VyaXR5IGNoYW5nZS4NCj4+DQo+PiBSaWdodC4gU2VlIHBvaW50cyA1IGFuZCA2LiBQcm9iYWJs
eSBNZXNzYWdlLUF1dGhlbnRpY2F0b3IgTVVTVCBiZSBjYWxjdWxhdGVkIG92ZXIgdGhlIHdob2xl
IHBhY2tldCwgbm90IG9ubHkgdGhlIHN1YnNldC4NCj4NCj4gTWVzc2FnZS1BdXRoZW50aWNhdG9y
IGlzIGEgaG9wLWJ5LWhvcCBhdXRoZW50aWNhdG9yIHNvIEkgZG8gbm90IHRoaW5rIGl0IGNhbiBi
ZSBjYWxjdWxhdGVkIG92ZXIgdGhlIHdob2xlIHBhY2tldC4gT25lIGFsdGVybmF0aXZlIGlzIGp1
c3QgZGVzY3JpYmluZyB3aGF0IEppbSBwcm9wb3NlcyBieSBhZGRpbmcgc29tZSBub3RlIHRvIHNl
Y3VyaXR5IGNvbnNpZGVyYXRpb25zLiBPdGhlciBhbHRlcm5hdGl2ZSBtaWdodCBiZSB0byBpbmNs
dWRlIE1lc3NhZ2UtQXV0aGVudGljYXRvciBhdHRyaWJ1dGUgaW4gYWxsIGNodW5rcyBmcm9tIHRo
ZSBvbmUgd2hpY2ggcmVxdWlyZXMgaXQuIEZvciBleGFtcGxlIGlmIGEgUkFESVVTIEFjY2Vzcy1B
Y2NlcHQgY2FycmllcyBhbiBFQVAtU3VjY2VzcyBhbmQgYSBzZXQgb2YgYXR0cmlidXRlcyB0aGF0
IGRvIG5vdCBmaXQgaW4gdGhlIHBhY2tldCwgTWVzc2FnZS1BdXRoZW50aWNhdG9yIGlzIGluY2x1
ZGVkIGluIHRoYXQgUkFESVVTIEFjY2Vzcy1BY2NlcHQgYW5kIGluIGFsbCBjaHVua3MgZnJvbSB0
aGF0IG1lc3NhZ2UgdW50aWwgYWxsIGNodW5rcyBoYXZlIGJlZW4gc2VudC4NCg0KDQpUYWtpbmcg
aW50byBhY2NvdW50IHRoZSBuYXR1cmUgb2YgTWVzc2FnZS1BdXRoZW50aWNhdG9yIEkgZG8gbm90
IHNlZSBhIHNlcmlvdXMNCnJpc2sgaW4gdGhlIGNoYW5nZSBkZWFsaW5nIHdpdGggZnJhZ21lbnRz
IGltcGx5LCBzbyBqdXN0IG5vdGluZyB0aGlzIGlzc3VlIGluIHRoZSBzZWN1cml0eSBjb25zaWRl
cmF0aW9ucyBzaG91bGQgYmUgZW5vdWdoLg0KDQpCZSBnb29kZSwNCg0KLS0NCiJFc3RhIHZleiBu
byBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxl
Zm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUtbWFpbDog
ZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1
MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBl
eGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEg
cG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBl
biBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVk
IGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUg
ZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50
aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg==

From alex@um.es  Wed Jan 30 00:37:19 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C9821F854D for ; Wed, 30 Jan 2013 00:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.698
X-Spam-Level: 
X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[AWL=0.900,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 o665aC1z73ba for ; Wed, 30 Jan 2013 00:37:18 -0800 (PST)
Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 22BEF21F84C5 for ; Wed, 30 Jan 2013 00:37:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id ACFAB4BF22 for ; Wed, 30 Jan 2013 09:37:16 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon12.um.es
Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EdNFxMQcV6GJ for ; Wed, 30 Jan 2013 09:37:16 +0100 (CET)
Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id 0D02E4BEAB for ; Wed, 30 Jan 2013 09:37:15 +0100 (CET)
Message-ID: <5108DBBB.3050406@um.es>
Date: Wed, 30 Jan 2013 09:37:15 +0100
From: Alejandro Perez Mendez 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: radext@ietf.org
References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es>
In-Reply-To: <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es>
Content-Type: multipart/alternative; boundary="------------060406010008080209020708"
Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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: Wed, 30 Jan 2013 08:37:19 -0000

This is a multi-part message in MIME format.
--------------060406010008080209020708
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Yoshi, Rafa,

see some comments inline:


> Dear all,
>
> we have received additional comments from Yoshihiro Ohba (many thanks) that we share with you.
>
> Please, see some comments inline.
>
> "Here is my review of draft-perez-radext-radius-fragmentation-04.
>
> Section 1:
>
> "Each RADIUS packet can transport several RADIUS attributes, to convey
> the necessary information to the other peer, up to a maximum size of 4
> KB of total data (including RADIUS packet headers)."
>
> [YO] I suggest to replace "4 KB" with "4096 bytes" throughout the
> document since "KB" can mean 4000 bytes in some cases.
>
> [Rafa] OK.
>
>
> "A reference-based mechanism is also proposed in [RFC6158], where
> attributes can be obtained through an out-of-band protocol."
>
> [YO} Meaning of this sentence is unclear. Does this mean RADIUS
> attributes are obtained through some other protocol instead of RADIUS?
> Or does this mean the actual format of the Value field of a RADIUS
> Attribute is defined in other protocol specification? In the latter
> case, it should be also mentioned that RADIUS-EAP is categorized as the
> mechanism defined in RFC 6158.
>
> [Rafa] It is referring the value of the attributes can be obtained by other protocol instead of RADIUS. This is coming from a previous comment related with SAML transport. Instead of transporting the real SAML messages an URL is set as attribute value. We can try to clarify a little bit more.
>
> "However, there are no proposals to deal with fragmentation at a packet
> level, when the total size exceeds the 4 KB limit imposed by the RADIUS
> specification."
>
> [YO] Meaning of "at a packet level" is unclear. Suggested change:
> "However, there are no proposals to fragement a large-sized RADIUS
> packet into multiple small-sized RADIUS packets, where the length of the
> original (unfragmented) RADIUS packet exceeds the 4096-octet limit
> imposed by the RADIUS specification."
>
> [Rafa] This sounds good.
>
>
> Section 2:
>
> [YO] I am not sure if "T" flag is needed. In other words, it should be
> possible to change [I-D.ietf-radext-radius-extensions] to simply allow a
> fragment with the M-flag cleared not to be included in a non-last chunk.
>
> [Rafa]
>
> Yes, that may be possible. It is worth noting that we wanted to keep unmodified any existing I-D by the time being. Moreover, [I-D.ietf-radext-radius-extensions] has not considered that fragmentation at packet level may occur for obvious reasons. Moreover, that I-D is in a mature state now.
>
> In any case, we may ask authors of [I-D.ietf-radext-radius-extensions].
>
> Section 3.3:
>
> [YO] Access-Accept fragmentation scheme looks odd compared to
> Access-Request and Access-Challenge fragmentation schemes. There are
> several questions related to this: (1) Why multiple chunks of
> Access-Accept cannot be sent without having an Access-Challange to be
> sent in between? (2) Why an Access-Accept cannot contain a
> More-Data-Pending attribute instead of using a new service type value?
> (3) How can a large attributue that is allowed to appear in an
> Access-Accept but not allowed to appear in Access-Challenge be fragmented?
>
> [Rafa]
>
> 1) We wanted to be symmetric in the design, where Access-Request/Access-Challenge exchange is used somehow for fragmentation support. In any case, we have also considered the usage of Access-Accept with Service-Type[AddAuth] so until all the attributes in the whole RADIUS Access-Accept are finally sent the exchange will be Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one is simply Access-Request/Access-Accept. This mode of operation would solve your question 3).
>
> 2) I think that may be also possible. In any case, I think Alan or Alex can elaborate a little bit a more about the usage of Service-Type[AddAuth].
>
> 3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think?

This alternative sounds good to me. However, I think there may be still 
some advantages of using Service-Type instead of (or in addition to) 
More-Data-Pending for Access-Accept packets.

If the NAS/RP does not know anything about fragmentation (i.e. does not 
support this draft), it may take the first Access-Accept chunk, ignore 
the More-Data-Pending attribute (it is unknown for it), and process it 
as a complete packet. As no additional round-trip is mandatory after an 
Access-Accept packet, it may be problematic as it is possible that part 
of the obligations from the AS to the NAS (e.g. FW policies) are not 
enforced.

However, RFC 2865 says that (in relation to Access-Accept packets):

    A NAS is not
           required to implement all of these service types, and MUST treat
           unknown or unsupported Service-Types as though an Access-Reject
           had been received instead


Therefore, if the NAS does not understand 
Service-Type=AdditionalAuthorization, the Access-Accept packet will be 
interpreted as an Access-Reject one, which seems to be the most 
reasonable approach.

This sort of problems seem to not be critical with Access-Challenge 
packets, as the NAS is expected to generate a new Access-Request packet 
afterwards, and the AS can detect whether fragmentation was supported.

Regards,
Alejandro

>
> Section 8:
>
> [YO] Security Considerations section is too short. Security mechansims
> that are needed for secure operation of the proposed fragmentation
> mechanism needs to be described in this section.
>
> [Rafa] Yes this section will be improved. Jim also raised comments about it.
>
> Section 9:
>
> [YO] I don't think the following statement is true: "This document has
> no actions for IANA." because Section 6 defines new attributes.
>
> [Rafa] Correct. This needs to be fixed.
>
> Best Regards,
> Yoshihiro Ohba
> "
>
> Best regards.
>
> -------------------------------------------------------
> Rafael Marin Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
> -------------------------------------------------------
>
>
>
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext


--------------060406010008080209020708
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hello Yoshi, Rafa, 

    

    see some comments inline:

    

    


    

    

      
Dear all,

we have received additional comments from Yoshihiro Ohba (many thanks) that we share with you. 

Please, see some comments inline.

"Here is my review of draft-perez-radext-radius-fragmentation-04.

Section 1:

"Each RADIUS packet can transport several RADIUS attributes, to convey
the necessary information to the other peer, up to a maximum size of 4
KB of total data (including RADIUS packet headers)."

[YO] I suggest to replace "4 KB" with "4096 bytes" throughout the
document since "KB" can mean 4000 bytes in some cases.

[Rafa] OK.


"A reference-based mechanism is also proposed in [RFC6158], where
attributes can be obtained through an out-of-band protocol."

[YO} Meaning of this sentence is unclear. Does this mean RADIUS
attributes are obtained through some other protocol instead of RADIUS?
Or does this mean the actual format of the Value field of a RADIUS
Attribute is defined in other protocol specification? In the latter
case, it should be also mentioned that RADIUS-EAP is categorized as the
mechanism defined in RFC 6158.

[Rafa] It is referring the value of the attributes can be obtained by other protocol instead of RADIUS. This is coming from a previous comment related with SAML transport. Instead of transporting the real SAML messages an URL is set as attribute value. We can try to clarify a little bit more.

"However, there are no proposals to deal with fragmentation at a packet
level, when the total size exceeds the 4 KB limit imposed by the RADIUS
specification."

[YO] Meaning of "at a packet level" is unclear. Suggested change:
"However, there are no proposals to fragement a large-sized RADIUS
packet into multiple small-sized RADIUS packets, where the length of the
original (unfragmented) RADIUS packet exceeds the 4096-octet limit
imposed by the RADIUS specification."

[Rafa] This sounds good.


Section 2:

[YO] I am not sure if "T" flag is needed. In other words, it should be
possible to change [I-D.ietf-radext-radius-extensions] to simply allow a
fragment with the M-flag cleared not to be included in a non-last chunk.

[Rafa] 

Yes, that may be possible. It is worth noting that we wanted to keep unmodified any existing I-D by the time being. Moreover, [I-D.ietf-radext-radius-extensions] has not considered that fragmentation at packet level may occur for obvious reasons. Moreover, that I-D is in a mature state now.

In any case, we may ask authors of [I-D.ietf-radext-radius-extensions].

Section 3.3:

[YO] Access-Accept fragmentation scheme looks odd compared to
Access-Request and Access-Challenge fragmentation schemes. There are
several questions related to this: (1) Why multiple chunks of
Access-Accept cannot be sent without having an Access-Challange to be
sent in between? (2) Why an Access-Accept cannot contain a
More-Data-Pending attribute instead of using a new service type value?
(3) How can a large attributue that is allowed to appear in an
Access-Accept but not allowed to appear in Access-Challenge be fragmented?

[Rafa]

1) We wanted to be symmetric in the design, where Access-Request/Access-Challenge exchange is used somehow for fragmentation support. In any case, we have also considered the usage of Access-Accept with Service-Type[AddAuth] so until all the attributes in the whole RADIUS Access-Accept are finally sent the exchange will be Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one is simply Access-Request/Access-Accept. This mode of operation would solve your question 3).

2) I think that may be also possible. In any case, I think Alan or Alex can elaborate a little bit a more about the usage of Service-Type[AddAuth].

3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think?  

    

    

    This alternative sounds good to me. However, I think there may be
    still some advantages of using Service-Type instead of (or in
    addition to) More-Data-Pending for Access-Accept packets.

    

    If the NAS/RP does not know anything about fragmentation (i.e. does
    not support this draft), it may take the first Access-Accept chunk,
    ignore the More-Data-Pending attribute (it is unknown for it), and
    process it as a complete packet. As no additional round-trip is
    mandatory after an Access-Accept packet, it may be problematic as it
    is possible that part of the obligations from the AS to the NAS
    (e.g. FW policies) are not enforced.

    

    However, RFC 2865 says that (in relation to Access-Accept packets):

    

      
A NAS is not
      required to implement all of these service types, and MUST treat
      unknown or unsupported Service-Types as though an Access-Reject
      had been received instead

    

    

    Therefore, if the NAS does not understand
    Service-Type=AdditionalAuthorization, the Access-Accept packet will
    be interpreted as an Access-Reject one, which seems to be the most
    reasonable approach.

    

    This sort of problems seem to not be critical with Access-Challenge
    packets, as the NAS is expected to generate a new Access-Request
    packet afterwards, and the AS can detect whether fragmentation was
    supported.

    

    Regards,

    Alejandro

    

    

      

Section 8:

[YO] Security Considerations section is too short. Security mechansims
that are needed for secure operation of the proposed fragmentation
mechanism needs to be described in this section.

[Rafa] Yes this section will be improved. Jim also raised comments about it.

Section 9:

[YO] I don't think the following statement is true: "This document has
no actions for IANA." because Section 6 defines new attributes.

[Rafa] Correct. This needs to be fixed.

Best Regards,
Yoshihiro Ohba
"

Best regards.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------




_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext


    

    

  


--------------060406010008080209020708--

From bernard_aboba@hotmail.com  Wed Jan 30 23:18:35 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A3321F86F4 for ; Wed, 30 Jan 2013 23:18:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.15
X-Spam-Level: 
X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 0+TuzPaaljKs for ; Wed, 30 Jan 2013 23:18:33 -0800 (PST)
Received: from blu0-omc3-s33.blu0.hotmail.com (blu0-omc3-s33.blu0.hotmail.com [65.55.116.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9020D21F84E0 for ; Wed, 30 Jan 2013 23:18:33 -0800 (PST)
Received: from BLU405-EAS376 ([65.55.116.74]) by blu0-omc3-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jan 2013 23:18:33 -0800
X-EIP: [fHQqkv40Ks6T548dQXovZq+yiC/v5WAQ]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_72adbac9-5bd7-487a-a5a4-b638151f8c3f_"
Date: Wed, 30 Jan 2013 23:18:29 -0800
From: Bernard Aboba 
To: siva kumar 
MIME-Version: 1.0
X-OriginalArrivalTime: 31 Jan 2013 07:18:33.0180 (UTC) FILETIME=[2D7121C0:01CDFF83]
Cc: radext@ietf.org, Dave Nelson , Alan DeKok 
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 31 Jan 2013 07:18:35 -0000

--_72adbac9-5bd7-487a-a5a4-b638151f8c3f_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Putting an EAP-Failure in an Access-Accept or an EAP-Success in an Access-R=
eject is NOT RECOMMENDED in RFC 3579. Also=2C the NAS is an EAP pass throug=
h and modifying EAP packets as you state is a DoS attack on the supplicant.

siva kumar  wrote:

Hi All=2C

I have one more question:

In case of 802.1x authentication (EAP and radius)=2C if the radius server
sends a access-accept with a service type that
is not supported by NAS=2C it is recommended that the NAS assumes it to be =
a
access-reject=2C but is it OK for the NAS(which
acts as passthru) to decode the EAP success message sent in radius
access-accept message and modify it as a EAP failure
and send it to the supplicant.

Thanks & Regards=2C
Sivakumar.S

On Fri=2C Jan 25=2C 2013 at 12:29 PM=2C siva kumar wrote:

> Hi Dave/Alan/Bernard/Others=2C
>
> Thanks all for the valuable inputs. It is evident that our NAS
> implementation is not acceptable as per your views. And Our NAS
> is not interoperable with most of the radius servers. We will consider al=
l
> your inputs and re-architect our implementation.
>
> Thanks again.
>
> Regards=2C
> Sivakumar.S
>
>
> On Fri=2C Jan 25=2C 2013 at 12:57 AM=2C Dave Nelson  =
wrote:
>
>> On Thu=2C Jan 24=2C 2013 at 2:18 PM=2C Bernard Aboba
>>  wrote:
>>
>> > [BA] That text is about Access-Accept=2C not Access-Challenge.  An
>> > Access-Challenge is not about provisioning services (the decision on
>> whether
>> > to Accept or Reject has not been made yet).  Given that=2C I believe t=
hat
>> > ignoring attributes that aren't understood is probably fine.  Even
>> > attributes that might be considered mandatory in an Accept (e.g.
>> filters)
>> > can probably be safely ignored in an Access-Challenge.
>>
>> Agreed.
>>
>> Regards=2C
>>
>> Dave
>>
>> David B. Nelson
>> Director of Technology
>> Elbrys Networks=2C Inc.
>> www.elbrys.com
>> +1.603.570.2636
>>
>
>

--_72adbac9-5bd7-487a-a5a4-b638151f8c3f_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"










Putting an EAP-Failure in an Access-Accept or an E=
AP-Success in an Access-Reject is NOT RECOMMENDED in RFC 3579. Also=2C the =
NAS is an EAP pass through and modifying EAP packets as you state is a DoS =
attack on the supplicant.




siva kumar <=3Bshiv.annauniv@gmail.com>=3B wrote:







Hi All=2C



I have one more question:



In case of 802.1x authentication (EAP and radius)=2C if the radius server s=
ends a access-accept with a service type that

is not supported by NAS=2C it is recommended that the NAS assumes it to be =
a access-reject=2C but is it OK for the NAS(which

acts as passthru) to decode the EAP success message sent in radius access-a=
ccept message and modify it as a EAP failure


and send it to the supplicant. 



Thanks &=3B Regards=2C

Sivakumar.S




On Fri=2C Jan 25=2C 2013 at 12:29 PM=2C siva k=
umar 
<=3Bshiv.ann=
auniv@gmail.com>=3B wrote:



Hi Dave/Alan/Bernard/Others=2C



Thanks all for the valuable inputs. It is evident that our NAS implementati=
on is not acceptable as per your views. And Our NAS

is not interoperable with most of the radius servers. We will consider all =
your inputs and re-architect our implementation.



Thanks again.



Regards=2C

Sivakumar.S








On Fri=2C Jan 25=2C 2013 at 12:57 AM=2C Dave N=
elson 
<=3Bdnelson@elbry=
s.com>=3B wrote:




On Thu=2C Jan 24=2C 2013 at 2:18 PM=2C Bernard Aboba

<=3Bbernar=
d_aboba@hotmail.com>=3B wrote:



>=3B [BA] That text is about Access-Accept=2C not Access-Challenge.  =
=3BAn

>=3B Access-Challenge is not about provisioning services (the decision on=
 whether

>=3B to Accept or Reject has not been made yet).  =3BGiven that=2C I =
believe that

>=3B ignoring attributes that aren't understood is probably fine.  =
=3BEven

>=3B attributes that might be considered mandatory in an Accept (e.g. fil=
ters)

>=3B can probably be safely ignored in an Access-Challenge.





Agreed.






Regards=2C



Dave



David B. Nelson

Director of Technology

Elbrys Networks=2C Inc.

www.elbrys.com

+=3B1.603.570.2636


























--_72adbac9-5bd7-487a-a5a4-b638151f8c3f_--

From dnelson@elbrys.com  Thu Jan 31 04:54:48 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD8D21F89E1 for ; Thu, 31 Jan 2013 04:54:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.727
X-Spam-Level: 
X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 YrxzO1q6xHGe for ; Thu, 31 Jan 2013 04:54:47 -0800 (PST)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 49D4221F8803 for ; Thu, 31 Jan 2013 04:54:46 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id hq4so415781wib.12 for ; Thu, 31 Jan 2013 04:54:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=M6NL2oD8BxmUOMh5Bnyxy2Q0RgrOA+lkdp2SCb5h3Lc=; b=dacYwvEpzA/Vt8aVSapOQjCABUkz+p6Y3QY2McDLCoFHDC2L+albur8gL3sEreVbS2 0cPrgI5/eMX40eq0TnBV7L+NPzoWVscb4zRlucpGpYiQpBWMFHXCB0APIZAK4EtMxTAr nbL1s3yf814VKFF6IPSy4PWwt1gDNLfpMTvy6Arg1QnQRTbWJX1qeGLQWbB2T46D0ZSq muVtVb/YmnDa04kO1/1UYeD4N4+RcUyAG5RUUWf53lQbuz3m9/DbHi7ZhfBP1PSTWpxK pYCyjFacBps3s0tijNkdTp9qJpvJcf5ff5j2QgS6GSUoX5Y2UW3mPMIKXZQXFHWakByG hJDA==
MIME-Version: 1.0
X-Received: by 10.194.77.13 with SMTP id o13mr15201965wjw.58.1359636886150; Thu, 31 Jan 2013 04:54:46 -0800 (PST)
Received: by 10.194.248.199 with HTTP; Thu, 31 Jan 2013 04:54:46 -0800 (PST)
In-Reply-To: 
References:  
Date: Thu, 31 Jan 2013 07:54:46 -0500
Message-ID: 
From: Dave Nelson 
To: siva kumar 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQn+x+nKSPyZFUr9ARKXrxhHADWmQtgTmBw5VqFplIP+V2r1mzPkKNoPpktsmCyrqbr3WmkL
Cc: Bernard Aboba , radext@ietf.org, Alan DeKok 
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 31 Jan 2013 12:54:48 -0000

On Thu, Jan 31, 2013 at 2:23 AM, siva kumar  wrote:

> If service type is not supported and if NAS consider access-accept as
> access-reject, is it ok to not authenticate/authorize the port
> without sending eap failure. Will this create an unending authentication
> retries.

I think what you're asking is what's the best way for the NAS to
signal to the end user, via the 802.1X supplicant, that the RADIUS
Server is misconfigured.  After all, if EAP authentication succeeds,
but the RADUS Server provisions a service the NAS cannot deliver, the
server is very likely misconfigured.  My answer is anything that gets
the end user to call the Help Desk and open a trouble ticket.  :-)

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

From aland@deployingradius.com  Thu Jan 31 14:43:24 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83CC21F8621 for ; Thu, 31 Jan 2013 14:43:24 -0800 (PST)
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 Unv2wAPLlESh for ; Thu, 31 Jan 2013 14:43:24 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id E610321F8583 for ; Thu, 31 Jan 2013 14:43:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D78F42240CB4; Thu, 31 Jan 2013 23:42:23 +0100 (CET)
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 WgzVIpPaNPXb; Thu, 31 Jan 2013 23:42:23 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id B78AC2240A2D; Thu, 31 Jan 2013 23:42:22 +0100 (CET)
Message-ID: <510AF34C.2010201@deployingradius.com>
Date: Thu, 31 Jan 2013 17:42:20 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: "radext@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [radext] Data types in RADIUS
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, 31 Jan 2013 22:43:24 -0000

  I wrote yet another draft.  It's not on the RADEXT charter, but I
think it is useful.

http://www.ietf.org/id/draft-dekok-radext-datatypes-00.txt

  In short, RFC 2865 Section 5 names and defines data types.  The later
RFCs didn't continue this practice.  They often didn't use the data
types defined by RFC 2865.

  This draft addresses that issue.  It names the data types, defines
them, creates an IANA registry for RADIUS data types, and updates the
"RADIUS Attribute Type" registry to include a "data type" column.

  There are no changes required for any implementation; past, present,
or future.  This document just makes the specifications match two
decades of RADIUS practice: attributes are defined as (number, name,
data type).

  Any comments are welcome.

  Alan DeKok.

From mikem@open.com.au  Thu Jan 31 15:03:38 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8688D21F8561 for ; Thu, 31 Jan 2013 15:03:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level: 
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, IP_NOT_FRIENDLY=0.334, 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 UtqFi9JK51JJ for ; Thu, 31 Jan 2013 15:03:37 -0800 (PST)
Received: from mail.open.com.au (mail.open.com.au [67.192.60.197]) by ietfa.amsl.com (Postfix) with ESMTP id BE72821F8528 for ; Thu, 31 Jan 2013 15:03:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.open.com.au (Postfix) with ESMTP id 5704D11309E4; Thu, 31 Jan 2013 17:03:37 -0600 (CST)
X-Virus-Scanned: amavisd-new at example.com
Received: from mail.open.com.au ([127.0.0.1]) by localhost (228755-app1.open.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4i24bLnOkrQK; Thu, 31 Jan 2013 17:03:33 -0600 (CST)
Received: from zulu.localnet (135.35.96.58.static.exetel.com.au [58.96.35.135]) by mail.open.com.au (Postfix) with ESMTP id DC96F11309E2; Thu, 31 Jan 2013 17:03:32 -0600 (CST)
From: Mike McCauley 
To: radext@ietf.org
Date: Fri, 01 Feb 2013 09:03:31 +1000
Message-ID: <3812338.DVBky6AyNd@zulu>
Organization: Open System Consultants
User-Agent: KMail/4.8.5 (Linux/3.4.11-2.16-desktop; KDE/4.8.5; i686; ; )
In-Reply-To: <510AF34C.2010201@deployingradius.com>
References: <510AF34C.2010201@deployingradius.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: Alan DeKok 
Subject: Re: [radext] Data types in RADIUS
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, 31 Jan 2013 23:03:38 -0000

Hi Alan,

It seems that there are some WiMAX VSA's that can contain either a v4 or a v6 
address, such as 

HA-IP-MIP4

Description The IPv4 address of the HA for CMIP4..
Length 6 + 3 + ( 4 for IPv4 or 16 for IPv6 )

(there are other similar ones)

I dont think that possibility is covered by the types you have defined so far?

Cheers,

On Thursday, January 31, 2013 05:42:20 PM Alan DeKok wrote:
>   I wrote yet another draft.  It's not on the RADEXT charter, but I
> think it is useful.
> 
> http://www.ietf.org/id/draft-dekok-radext-datatypes-00.txt
> 
>   In short, RFC 2865 Section 5 names and defines data types.  The later
> RFCs didn't continue this practice.  They often didn't use the data
> types defined by RFC 2865.
> 
>   This draft addresses that issue.  It names the data types, defines
> them, creates an IANA registry for RADIUS data types, and updates the
> "RADIUS Attribute Type" registry to include a "data type" column.
> 
>   There are no changes required for any implementation; past, present,
> or future.  This document just makes the specifications match two
> decades of RADIUS practice: attributes are defined as (number, name,
> data type).
> 
>   Any comments are welcome.
> 
>   Alan DeKok.
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
-- 
Mike McCauley                               mikem@open.com.au
Open System Consultants Pty. Ltd
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.


From aland@deployingradius.com  Thu Jan 31 15:27:25 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957FC21F8460 for ; Thu, 31 Jan 2013 15:27:25 -0800 (PST)
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 eDiui-lg6byD for ; Thu, 31 Jan 2013 15:27:24 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F54E21F8455 for ; Thu, 31 Jan 2013 15:27:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 776412240CB4; Fri,  1 Feb 2013 00:27:23 +0100 (CET)
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 g+a-J-2EhhYc; Fri,  1 Feb 2013 00:27:21 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 6E69D2240C9B; Fri,  1 Feb 2013 00:27:21 +0100 (CET)
Message-ID: <510AFDD7.3030400@deployingradius.com>
Date: Thu, 31 Jan 2013 18:27:19 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Mike McCauley 
References: <510AF34C.2010201@deployingradius.com> <3812338.DVBky6AyNd@zulu>
In-Reply-To: <3812338.DVBky6AyNd@zulu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: radext@ietf.org
Subject: Re: [radext] Data types in RADIUS
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, 31 Jan 2013 23:27:25 -0000

Mike McCauley wrote:
> It seems that there are some WiMAX VSA's that can contain either a v4 or a v6 
> address, such as 
> 
> HA-IP-MIP4

  Yes.

> I dont think that possibility is covered by the types you have defined so far?

  It isn't covered by the data types in the draft.  RFC 6158 Section 3.4
suggests that polymorphic types are "NOT RECOMMENDED".

  My idea with this draft is to define standard data types.  More can be
defined later.

  I expect that implementations will use non-standard data types.  i.e.
FreeRADIUS has 8-bit integer, 16-bit integer, MAC address, the WiMAX
IPv4/6 address, among others.  What is practical may not always be
suitable for standards action.

  Alan DeKok.

From aland@deployingradius.com  Thu Jan 31 18:47:10 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A6B21F8794 for ; Thu, 31 Jan 2013 18:47:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.449
X-Spam-Level: 
X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_STOP=2.3, 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 qSusdKV2YCwc for ; Thu, 31 Jan 2013 18:47:09 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5861121F8780 for ; Thu, 31 Jan 2013 18:47:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id C86282240CB4 for ; Fri,  1 Feb 2013 03:47:08 +0100 (CET)
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 If+ZR4SXkHEX for ; Fri,  1 Feb 2013 03:47:06 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 43AB52240A2D for ; Fri,  1 Feb 2013 03:47:06 +0100 (CET)
Message-ID: <510B2CA9.7050004@deployingradius.com>
Date: Thu, 31 Jan 2013 21:47:05 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: "radext@ietf.org" 
Content-Type: multipart/mixed; boundary="------------050801090001050209070800"
Subject: [radext] [Fwd: Issues with draft-ietf-radext-radius-extensions-09]
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, 01 Feb 2013 02:47:11 -0000

This is a multi-part message in MIME format.
--------------050801090001050209070800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  FYI.  I'm not sure I agree with all of the comments here.  I will have
a more detailed response later.

  This email is just to let the WG know the IESG's review of the document.

  Alan DeKok.

--------------050801090001050209070800
Content-Type: message/rfc822;
 name="Issues with draft-ietf-radext-radius-extensions-09.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0="Issues with draft-ietf-radext-radius-extensions-09.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;
	 Fri, 01 Feb 2013 02:18:23 +0100
X-Sieve: CMU Sieve 2.4
Received: from localhost (localhost [127.0.0.1])
	by power.freeradius.org (Postfix) with ESMTP id EA3032240CB4
	for ; Fri,  1 Feb 2013 02:18:22 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Authentication-Results: power.freeradius.org (amavisd-new); dkim=pass
	header.i=@gmail.com
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 eie9NUQl62zq for ;
	Fri,  1 Feb 2013 02:18:18 +0100 (CET)
Received-SPF: None (no SPF record) identity=mailfrom; client-ip=77.72.230.30; helo=grenache.tools.ietf.org; envelope-from=draft-alias-bounces@tools.ietf.org; receiver=aland@networkradius.com 
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30])
	by power.freeradius.org (Postfix) with ESMTPS id 8F42E2240A2D
	for ; Fri,  1 Feb 2013 02:18:17 +0100 (CET)
Received: from mail-lb0-f178.google.com ([209.85.217.178]:35091)
	by grenache.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128)
	(Exim 4.80)
	(envelope-from )
	id 1U15Gd-0003IY-12; Fri, 01 Feb 2013 02:18:12 +0100
Received: by mail-lb0-f178.google.com with SMTP id n1so3956677lba.23
        for ; Thu, 31 Jan 2013 17:18:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:x-received:sender:date:x-google-sender-auth:message-id
         :subject:from:to:cc:content-type;
        bh=r0I7JQ1nK86NufSBVOg4qCwnLTihOECee+6dQmQky8k=;
        b=O5U3j9Z9nJsqszij6NaVk4vurp9Q0msh/+1XEMkq3g139Vj5gom4d4Fr/bAJQDw8Vz
         8BSffB59GPsJ4xtqNyvF1DO1B9JOgL0nxO3g2QgnmX0MjGR8hOlXEzk5lVmMDcQ4jiXx
         qcru80LyD7UAu1bZMZOLQKy/9TYgH1u7khEmbINuSbfZgrWOub3Ov00Ujd7jX4wvvOxu
         fPILsVZvhyi4ob+0/cF1cWYbCbH96TI9dtJ6XdQc4n40VjTJy77F24ZSyU5vMtYX7Y8k
         +/bXa02M4G3bdKzUmd7d4gVUISflgIjiT482r4UxHlkUUvn940W+QAV4i9xVGD0DDVUR
         fYLA==
MIME-Version: 1.0
X-Received: by 10.112.98.197 with SMTP id ek5mr4051054lbb.80.1359681484757;
 Thu, 31 Jan 2013 17:18:04 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.112.47.168 with HTTP; Thu, 31 Jan 2013 17:18:04 -0800 (PST)
Date: Thu, 31 Jan 2013 20:18:04 -0500
X-Google-Sender-Auth: bqGUexVSUC4IFxLt8MJ2wJ4C91s
Message-ID: 
From: Barry Leiba 
To: draft-ietf-radext-radius-extensions@tools.ietf.org
Cc: radext-chairs@tools.ietf.org, radext-ads@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-SA-Exim-Connect-IP: 209.85.217.178
X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-extensions@tools.ietf.org, radext-chairs@tools.ietf.org, radext-ads@tools.ietf.org
X-SA-Exim-Mail-From: barryleiba@gmail.com
Subject: Issues with draft-ietf-radext-radius-extensions-09
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on grenache.tools.ietf.org)
Resent-To: aland@networkradius.com, avi@bridgewatersystems.com
Resent-To: jouni.nospam@gmail.com, mauricio.sanchez@hp.com,
Resent-To: bclaise@cisco.com, rbonica@juniper.net,
List-ID: 

Hi, all.

Authors, I've been reviewing the subject document for IESG Evaluation,
and I think I've found a bunch of internal conflicts and incorrect
things, which would end up as DISCUSS positions in my ballot.  I also
think that fixing these will need some re-review in the working group
to make sure that we got them right.  Rather than have a pile of
DISCUSS ballots and possible several ADs sifting through the same set
of errors, I've asked Benoit to remove the document from next week's
telechat while we work these out.  I apologize for the delay this
creates, but I really think it's the right thing.

I'm still finishing my review -- I'm just starting Section 5.2 now --
but I don't want the comments that I currently have to have to wait,
so I'm sending you what I have up to this point.  I'm going to try to
label each point with "DISCUSS" or "COMMENT", to indicate how I think
I'd ballot it.  Of course, some (I hope not all!) of my points could
just be a result of my not understanding something, so please discuss
these with me.  Let's see if we can sort this out quickly.

Meanwhile, I'll try to finish my review today (I'm in Japan now, and
it's 10 a.m. on Friday as I send this).

Barry Leiba, Applications AD
-----------------------------------------------------------

=== COMMENT ===
-- Section 1.1.1 --

   One goal which was not met by the above modifications is to have an
   incentive for standards to use the new space.  We would ideally like
   to deprecate the "Unassigned" attributes in the standard space, which
   would permit allocation, but under more stringent guidelines.
   However, [RFC5226] has no provisions for a "Deprecated" entry in an
   IANA managed registry.

It's actually entirely possible to deprecate items in a registry, so
if you still want to handle this.  The document could add a column to
the table, perhaps called "Status", which would have the values
"current" (or blank to mean "current") or "deprecated" (or "obsolete",
or whatever).  You can define in the document exactly what these
values mean, and ask IANA to put those definitions in the header at
the top of the registry.  You can populate that column as you please,
saying that all entries get "current" except [these], which get
"deprecated".

This has been done in other documents, with other registries; see, for
example, the Message Header Fields registry:
http://www.iana.org/assignments/message-headers/perm-headers.html

In those cases, the deprecated items are not re-assigned (as 5226
notes, re-assignment can be a problem).  But your document can
explicitly allow deprecated values to be re-assigned at some point,
however you want to set that up.  Of course, this itself could get
some questions from the IESG over concerns about double usage, but you
already have such double usage (as you note in Section 5), so....

-- Section 2.1 --

=== COMMENT ===
In the description of "Type":

I suggest adding a forward reference to make an important clarification here:

NEW
      This field is identical to the Type field of the Attribute format
      defined in [RFC2865] Section 5.  It will contain one of the Extended
      Type values defined in Section 3, below.
END

=== COMMENT ===
In the description of "Length":

      The Length field is one octet, and indicates the length of this
      Attribute including the Type, Length, Extended-Type, and Value
      fields.  Permitted values are between 4 and 255.  If a client or
      server receives an Extended Attribute with a Length of 2 or 3,
      then that Attribute MUST be considered to be an "invalid
      attribute", and handled as per Section 2.8, below.

Curious: What does a client or server do when it receives an Extended
Attribute with a length of 0 or 1?  (Same comment goes for Section
2.2.)

=== DISCUSS ===
Also, this doesn't make sense to me.  Section 2.8 starts with this:

   The term "invalid attribute" is new to this specification.  It is
   defined to mean that the Length field of an Attribute is valid (as
   per [RFC2865], Section 5, top of page 25).

These two appear to be contradictory: the first says that if the
length is invalid, it's an "invalid attribute", and the second says
that "invalid attribute" means that the length field is valid (but
there are other problems).  This comment also applies to "TLV-Length"
in Section 2.3.

=== DISCUSS ===
In the description of "Value":

      This field is similar to the Value field of the Attribute format
      defined in [RFC2865] Section 5.  The format of the data SHOULD be
      a valid RADIUS data type.

      The addition of the Extended-Type field decreases the maximum
      length for attributes of type "text" or "string" from 253 to 252
      octets.  Where an Attribute needs to carry more than 252 octets of
      data, the "Long Extended Type" format SHOULD be used.

The first SHOULD makes a subtle, but very significant change to the
RADIUS protocol, and I want to make sure what you're doing is what you
mean to do.  2865 says, "The format of the value field is one of five
data types." It has to be one of those types, and can't be anything
else -- nothing else is defined.  But you are now allowing an
implementor who understands the implications of doing so to use a
different data type.  So:

1. Do you really mean to allow that?
2. If "yes" to (1), what other data types exist that might be used?
Where are their formats defined?
3. If "yes" to (1), what *are* the implications of using other data types?

That comment also applies to "Value" in Section 2.2 and to "TLV-Value"
in Section 2.3.

For the second SHOULD, there's a similar issue: What are the
alternatives to using the "Long Extended Type" format?  What are the
implications of using those alternatives?

-- Section 2.2 --

=== COMMENT ===
In the description of "Type":

As in 2.1, I suggest adding a forward reference to make an important
clarification here:

NEW
      This field is identical to the Type field of the Attribute format
      defined in [RFC2865] Section 5.  It will contain one of the Long
      Extended Type values defined in Section 3, below.
END

=== DISCUSS ===
In the description of the "M" bit:

1.  The first two paragraphs contradict each other.  The first says
that M MUST be 0 if length < 255.  The second says, "When the More
field is set (1), the attribute SHOULD have a Length field of value
255".  According to the first paragraph, that needs to be MUST, not
SHOULD.  And then with that change, the next clause (about value 4)
can be removed.  The "that is" at the beginning of the third sentence
should be removed, because the ordering has not been mentioned before.

2.  The last sentence of the second paragraph ends, "and the last
attribute in a packet MUST NOT have the More field set (1)." That's
certainly true, but isn't what you really want to say that all pieces
of the entire fragmented attribute MUST be included in one packet?

3.  The third paragraph, which contradicts the first, should be removed.


In the description of "Value":

=== DISCUSS ===
      This field is similar to the Value field of the Attribute format
      defined in [RFC2865] Section 5.  It may contain a complete set of
      data (when the Length field has value less than 255), or it may
      contain a fragment of data (when the More field is set).

Isn't it possible for the Length field to be equal to 255 and to have
M=0 (if the last fragment of the fragmented attribute takes up the
whole 255 bytes, for instance)?  And doesn't the last fragment of a
fragmented attribute contain a fragment of data, even though the More
field is 0?

=== DISCUSS ===
      We note that the maximum size of a fragmented attribute is limited
      only by the RADIUS packet length limitation (i.e. 4096 octets, not
      counting various headers and overhead).  Implementations SHOULD be
      able to handle fragmented attributes of 4096 octets.

This is incorrect: the RADIUS packet length is limited to 4096 octets
*including* the various headers and overhead.  That puts a maximum
size of fragmented attributes as something less than 4096.  As I
compute it:

The RADIUS header is 20 octets, so that's 4096-20 = 4076 octets left
for attributes.  That will hold 15 fragments of 255 octets each, and a
16th fragment of 231 octets.  And that results in a total attribute
length (after headers are removed and the fragments are assembled) of
15*251+227 = 3992.

=== DISCUSS ===
The last paragraph of Section 2.2 says this:

   Implementations MUST be able to process non-
   contiguous fragments.  That is, fragments which are mixed together
   with other attributes of a different Type.

That contradicts what you said in the description of the "M" bit:

      That is, multiple
      fragments of the same value MUST be in order and MUST be
      consecutive attributes in the packet

=== DISCUSS ===
-- Section 2.3.1 --

   The depth of TLV nesting is limited only by the restrictions on the
   TLV-Length field.  The limit of 253 octets of data results in a limit
   of 126 levels of nesting.  However, nesting depths of more than 4 are
   NOT RECOMMENDED.

Again: Why is it NOT RECOMMENDED?  How would I know how to evaluate
the implications of going for more than 4 levels?

=== COMMENT ===
-- Section 2.7.2 --

The last paragraph seems out of place, as the following section
describes the TLV naming, basically repeating the last paragraph of
2.7.2.  I suggest correcting that organizational oddness.

=== COMMENT ===
-- Section 2.7.3 --

At the end of the first paragraph, I think "replied" should be "repeated".

=== COMMENT ===
-- Section 2.7.4 --

In the first sentence of the fourth paragraph, it seems as though "few
restrictions" is meant to be "a few restrictions", yes?

What does the example in paragraph 5 tell me that the example in
paragraph 3 doesn't?  That is, why is the second example needed?

=== COMMENT ===
-- Section 2.8 --

   For Attributes of type "Long Extended Type", an Attribute is
   considered to be an "invalid attribute" when does not match the
   criteria set out in Section 2.2, above.

1.  Typo: "when *it* does not match".

2.  I think it would be useful to remind implementors that one bad
apple spoils the whole bunch: that if one fragment of a fragmented
attribute is invalid, the entire attribute (all fragments) needs to be
considered invalid.

=== COMMENT ===
-- Sections 3 and 4 subsections --

It somewhat bothers me to have the diagrams and some information
repeated here (repeated repeatedly, in fact).  Is it not possible to
refer back to Sections 2.1 and 2.2 even more than you already do?
Perhaps like this?:

NEW
3.1.  Extended-Type-1

   Description

      This attribute encapsulates attributes of the "Extended Type"
      format, in the RADIUS Attribute Type Space of 241.{1-255}.
      See Section 2.1 for details and a diagram of the attribute
      format.

   Type

      241 for Extended-Type-1.

   Length

      >= 4

   Extended-Type

      See Section 2.1 for details.  Up-to-date values of this field
      are specified in the 241.{1-255} RADIUS Attribute Type Space.

   Value
      See Section 2.1 for details.
END

You might then also add the information in these two paragraphs to the
descriptions of "Value" in Sections 2.1 and 2.2:

      The Value field is one or more octets.  Implementations not
      supporting this specification SHOULD support the field as
      undistinguished octets.

      Implementations supporting this specification MUST use the
      Identifier of "Type.Extended-Type" to determine the interpretation
      of the Value field.

Does that make sense?

-----------------------------------------------------------

--------------050801090001050209070800--

From shiv.annauniv@gmail.com  Wed Jan 30 23:00:23 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE2D21F86DE for ; Wed, 30 Jan 2013 23:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.2
X-Spam-Level: 
X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=-0.201,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 Pz0LJvrzBvmJ for ; Wed, 30 Jan 2013 23:00:23 -0800 (PST)
Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 05A8A21F86B1 for ; Wed, 30 Jan 2013 23:00:22 -0800 (PST)
Received: by mail-oa0-f53.google.com with SMTP id m1so1721894oag.40 for ; Wed, 30 Jan 2013 23:00:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JuGm29QWYsbbVXHGtoJSUZQqm2M6LfEk1aSEnAoqzwk=; b=CWNYR/XV/ISz9Yfx+oqJa7JDEMHc+xUgwOnARYyGPWZt+4/Vh2aDx5JgtHlOHSRAj8 lgjmAt3c8tq9Co8ZC51e8a91sEvk+QH9QvoDiHZDSqLe2Eqqti3rBFXtY1xho0azyjYH CxlOC1WZjJ8csyDZ8XbpCrO2ir/M99ROfLp8ivcTLfKCUduK2zWYLvRqgqOghRMUZONM pFJnnhijsleVdT6IKOGO060YKIYyU0qVXF2eJYZpOTyyfSK/N1leciV4pQbb0k0IMUWe MxGfsbSrX986FlJwA7B5J3BmWLAYktFIadPrqTFn3h4xjAso4CCkVOEvMXFRLa6ofjlD GXZA==
MIME-Version: 1.0
X-Received: by 10.60.169.48 with SMTP id ab16mr5946787oec.72.1359615622559; Wed, 30 Jan 2013 23:00:22 -0800 (PST)
Received: by 10.182.232.42 with HTTP; Wed, 30 Jan 2013 23:00:22 -0800 (PST)
In-Reply-To: 
References:   
Date: Thu, 31 Jan 2013 12:30:22 +0530
Message-ID: 
From: siva kumar 
To: Dave Nelson 
Content-Type: multipart/alternative; boundary=bcaec54c4d6236b96204d4902e27
X-Mailman-Approved-At: Thu, 31 Jan 2013 23:24:43 -0800
Cc: Bernard Aboba , "radext@ietf.org" , Alan DeKok 
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 31 Jan 2013 07:00:24 -0000

--bcaec54c4d6236b96204d4902e27
Content-Type: text/plain; charset=ISO-8859-1

Hi All,

I have one more question:

In case of 802.1x authentication (EAP and radius), if the radius server
sends a access-accept with a service type that
is not supported by NAS, it is recommended that the NAS assumes it to be a
access-reject, but is it OK for the NAS(which
acts as passthru) to decode the EAP success message sent in radius
access-accept message and modify it as a EAP failure
and send it to the supplicant.

Thanks & Regards,
Sivakumar.S

On Fri, Jan 25, 2013 at 12:29 PM, siva kumar wrote:

> Hi Dave/Alan/Bernard/Others,
>
> Thanks all for the valuable inputs. It is evident that our NAS
> implementation is not acceptable as per your views. And Our NAS
> is not interoperable with most of the radius servers. We will consider all
> your inputs and re-architect our implementation.
>
> Thanks again.
>
> Regards,
> Sivakumar.S
>
>
> On Fri, Jan 25, 2013 at 12:57 AM, Dave Nelson  wrote:
>
>> On Thu, Jan 24, 2013 at 2:18 PM, Bernard Aboba
>>  wrote:
>>
>> > [BA] That text is about Access-Accept, not Access-Challenge.  An
>> > Access-Challenge is not about provisioning services (the decision on
>> whether
>> > to Accept or Reject has not been made yet).  Given that, I believe that
>> > ignoring attributes that aren't understood is probably fine.  Even
>> > attributes that might be considered mandatory in an Accept (e.g.
>> filters)
>> > can probably be safely ignored in an Access-Challenge.
>>
>> Agreed.
>>
>> Regards,
>>
>> Dave
>>
>> David B. Nelson
>> Director of Technology
>> Elbrys Networks, Inc.
>> www.elbrys.com
>> +1.603.570.2636
>>
>
>

--bcaec54c4d6236b96204d4902e27
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi All,

I have one more question:

In case of 802.1x authentic=
ation (EAP and radius), if the radius server sends a access-accept with a s=
ervice type that
is not supported by NAS, it is recommended that the NAS=
 assumes it to be a access-reject, but is it OK for the NAS(which

acts as passthru) to decode the EAP success message sent in radius access-a=
ccept message and modify it as a EAP failure 
and send it to the supplic=
ant. 

Thanks & Regards,
Sivakumar.S


On Fri, Jan 25, 2013 at 12:29 PM, siva kumar <shiv.annauniv@gmail.c=
om> wrote:

Hi Dave/Alan/Bernard/Others,

Thanks all for the valuable inputs. It =
is evident that our NAS implementation is not acceptable as per your views.=
 And Our NAS
is not interoperable with most of the radius servers. We wi=
ll consider all your inputs and re-architect our implementation.



Thanks again.

Regards,
Sivakumar.S


On Fri, Jan 25, 2013 at 12:=
57 AM, Dave Nelson <dnelson@elbrys.com> wrote:



On Thu, Jan 24, 2013=
 at 2:18 PM, Bernard Aboba

<bernard_=
aboba@hotmail.com> wrote:



> [BA] That text is about Access-Accept, not Access-Challenge. =A0An

> Access-Challenge is not about provisioning services (the decision on w=
hether

> to Accept or Reject has not been made yet). =A0Given that, I believe t=
hat

> ignoring attributes that aren't understood is probably fine. =A0Ev=
en

> attributes that might be considered mandatory in an Accept (e.g. filte=
rs)

> can probably be safely ignored in an Access-Challenge.




Agreed.




Regards,



Dave



David B. Nelson

Director of Technology

Elbrys Networks, Inc.

www.elbrys.com

+1.603.570.2636








--bcaec54c4d6236b96204d4902e27--

From shiv.annauniv@gmail.com  Wed Jan 30 23:23:51 2013
Return-Path: 
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3837F21F8481 for ; Wed, 30 Jan 2013 23:23:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.132
X-Spam-Level: 
X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 JCOmuC1dqcKH for ; Wed, 30 Jan 2013 23:23:50 -0800 (PST)
Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 144C321F8AA0 for ; Wed, 30 Jan 2013 23:23:49 -0800 (PST)
Received: by mail-oa0-f49.google.com with SMTP id j6so2623286oag.8 for ; Wed, 30 Jan 2013 23:23:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=a95jkLnFs60maaKnARyPOfkwcQPzskropalpAf+cQAg=; b=zSJ4v9ZRA9h3XOtEWTs2l/MJ0DCLf0JVWLM1KT46L/89s1mkmCDV+9SaiaFO+xiFZq RXFtid5zdz6YmwmOxpJCL3JvEHTIc5F03I1mn3S/XoJoPHFMh9qh5IcN6Rf5MzA8cDen kD7D+zc/uTLFFE8PbgzZavFocJdDCiixK5qrBpXIFKeUS5lbRipUV4r9RtZamDgvcXpA Tg6kjCXcQVzJpCS0HhcZf2rRGn49Gz7s/Kjv9QaKQPxmnz7GhAUUG+gjMHBVdgZk59sY TZ/SGz55PLqaMAEjwUug6GhYlxJem2mkpmU+tMckCMyk0e1iiehcyuiI3iAp9kscS5CV l7Aw==
MIME-Version: 1.0
X-Received: by 10.182.152.9 with SMTP id uu9mr5817387obb.9.1359617029501; Wed, 30 Jan 2013 23:23:49 -0800 (PST)
Received: by 10.182.232.42 with HTTP; Wed, 30 Jan 2013 23:23:49 -0800 (PST)
In-Reply-To: 
References: 
Date: Thu, 31 Jan 2013 12:53:49 +0530
Message-ID: 
From: siva kumar 
To: Bernard Aboba 
Content-Type: multipart/alternative; boundary=f46d044472c312f37504d490823b
X-Mailman-Approved-At: Thu, 31 Jan 2013 23:24:49 -0800
Cc: radext@ietf.org, Dave Nelson , Alan DeKok 
Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet
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, 31 Jan 2013 07:23:51 -0000

--f46d044472c312f37504d490823b
Content-Type: text/plain; charset=ISO-8859-1

If service type is not supported and if NAS consider access-accept as
access-reject, is it ok to not authenticate/authorize the port
without sending eap failure. Will this create an unending authentication
retries.

On Thu, Jan 31, 2013 at 12:48 PM, Bernard Aboba
wrote:

>  Putting an EAP-Failure in an Access-Accept or an EAP-Success in an
> Access-Reject is NOT RECOMMENDED in RFC 3579. Also, the NAS is an EAP pass
> through and modifying EAP packets as you state is a DoS attack on the
> supplicant.
>
> siva kumar  wrote:
>
>  Hi All,
>
> I have one more question:
>
> In case of 802.1x authentication (EAP and radius), if the radius server
> sends a access-accept with a service type that
> is not supported by NAS, it is recommended that the NAS assumes it to be a
> access-reject, but is it OK for the NAS(which
> acts as passthru) to decode the EAP success message sent in radius
> access-accept message and modify it as a EAP failure
> and send it to the supplicant.
>
> Thanks & Regards,
> Sivakumar.S
>
> On Fri, Jan 25, 2013 at 12:29 PM, siva kumar wrote:
>
> Hi Dave/Alan/Bernard/Others,
>
> Thanks all for the valuable inputs. It is evident that our NAS
> implementation is not acceptable as per your views. And Our NAS
> is not interoperable with most of the radius servers. We will consider all
> your inputs and re-architect our implementation.
>
> Thanks again.
>
> Regards,
> Sivakumar.S
>
>
> On Fri, Jan 25, 2013 at 12:57 AM, Dave Nelson  wrote:
>
> On Thu, Jan 24, 2013 at 2:18 PM, Bernard Aboba
>  wrote:
>
> > [BA] That text is about Access-Accept, not Access-Challenge.  An
> > Access-Challenge is not about provisioning services (the decision on
> whether
> > to Accept or Reject has not been made yet).  Given that, I believe that
> > ignoring attributes that aren't understood is probably fine.  Even
> > attributes that might be considered mandatory in an Accept (e.g. filters)
> > can probably be safely ignored in an Access-Challenge.
>
>  Agreed.
>
> Regards,
>
> Dave
>
> David B. Nelson
> Director of Technology
> Elbrys Networks, Inc.
> www.elbrys.com
> +1.603.570.2636
>
>
>
>

--f46d044472c312f37504d490823b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If service type is not supported and if NAS consider access-accept as acces=
s-reject, is it ok to not authenticate/authorize the port 
without sendi=
ng eap failure. Will this create an unending authentication retries.


On Thu, Jan 31, 2013 at 12:48 PM, Bernard Ab=
oba <bernard_aboba@hotmail.com> wrote:











Putting an EAP-Failure in an Access-Accept or an EAP-Success in an Acc=
ess-Reject is NOT RECOMMENDED in RFC 3579. Also, the NAS is an EAP pass thr=
ough and modifying EAP packets as you state is a DoS attack on the supplica=
nt.




siva kumar <shiv.annauniv@gmail.com> wrote:








Hi All,



I have one more question:



In case of 802.1x authentication (EAP and radius), if the radius server sen=
ds a access-accept with a service type that

is not supported by NAS, it is recommended that the NAS assumes it to be a =
access-reject, but is it OK for the NAS(which

acts as passthru) to decode the EAP success message sent in radius access-a=
ccept message and modify it as a EAP failure


and send it to the supplicant. 



Thanks & Regards,

Sivakumar.S




On Fri, Jan 25, 2013 at 12:29 PM, siva kumar 
<shiv.annau=
niv@gmail.com> wrote:



Hi Dave/Alan/Bernard/Others,



Thanks all for the valuable inputs. It is evident that our NAS implementati=
on is not acceptable as per your views. And Our NAS

is not interoperable with most of the radius servers. We will consider all =
your inputs and re-architect our implementation.



Thanks again.



Regards,

Sivakumar.S








On Fri, Jan 25, 2013 at 12:57 AM, Dave Nelson 
<dnelson@elbrys.=
com> wrote:




On Thu, Jan 24, 2013 at 2:18 PM, Bernard Aboba

<bernard_=
aboba@hotmail.com> wrote:



> [BA] That text is about Access-Accept, not Access-Challenge. =A0An

> Access-Challenge is not about provisioning services (the decision on w=
hether

> to Accept or Reject has not been made yet). =A0Given that, I believe t=
hat

> ignoring attributes that aren't understood is probably fine. =A0Ev=
en

> attributes that might be considered mandatory in an Accept (e.g. filte=
rs)

> can probably be safely ignored in an Access-Challenge.





Agreed.






Regards,



Dave



David B. Nelson

Director of Technology

Elbrys Networks, Inc.

www.elbrys.com

+1.603.570.2636






























--f46d044472c312f37504d490823b--