From nobody Mon Dec 1 23:39:50 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ECB1A0154 for ; Mon, 1 Dec 2014 23:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVeEp_dd77Zm for ; Mon, 1 Dec 2014 23:39:44 -0800 (PST) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id CF1C51A0151 for ; Mon, 1 Dec 2014 23:39:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id B907BADF for ; Tue, 2 Dec 2014 08:39:40 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5-wcHwpUM+e1 for ; Tue, 2 Dec 2014 08:39:40 +0100 (CET) Received: from [10.42.0.18] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id 81BA94CB for ; Tue, 2 Dec 2014 08:39:39 +0100 (CET) Message-ID: <547D6CBB.40908@um.es> Date: Tue, 02 Dec 2014 08:39:39 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: radext@ietf.org References: <54779834.9030205@cisco.com> In-Reply-To: <54779834.9030205@cisco.com> Content-Type: multipart/alternative; boundary="------------010503060806080203090809" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/CZjV28SA3MXeaO1CVNhdFXig6ZY Subject: Re: [radext] AD review: draft-ietf-radext-radius-fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 07:39:48 -0000 This is a multi-part message in MIME format. --------------010503060806080203090809 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear Benoit, thanks for the review. We will prepare a new revision considering your comments. Best regards, Alejandro El 27/11/14 a las 22:31, Benoit Claise escribió: > Dear all, > > Here is the AD review. > Note that I initiated a discussion with the IESG on the topic of an > experimental doc updating a Standard Track doc. More on this pretty > soon (hopefully). > > 1. > Since this is an experimental future RFC, the experiment should be > better explained. And if/when the experiment is successful, what's the > next step. > As an example, > http://tools.ietf.org/html/draft-ietf-radext-dtls-13#section-1.3 was > appreciated by the IESG. > Coming back to this draft, if the experiment is success, the Standard > Track version will update RFC 2865? > > 2. > Open question: Does this draft update RFC 6158? > The Length field in the RADIUS packet header is defined in[RFC2865] > Section 3 . It is noted there that the maximum length of a RADIUS > packet is 4096 octets. As a result, attribute designers SHOULD NOT > assume that a RADIUS implementation can successfully process RADIUS > packets larger than 4096 octets. > Or maybe this is taken care of by: > No such > exchange is possible for accounting or authorization data.[RFC6158] > Section 3.1 suggests that exchanging large amounts authorization data > is unnecessary in RADIUS. > > Or, maybe, if this experiment is successful, then the Standard Track > version will update RFC 6158? > > > _Editorial:_ > - > Your first sentence in the introduction speaks about "Authentication > Server (AS)", but some other parts of the document speak about "server" > Example: > In some cases, however, the > authorization data sent by the server is large and highly dynamic. > In other cases, the NAS needs to send large amounts of authorization > data to the server. > Btw, RFC 6158 speaks of RADIUS Server, which I believe is the right term. > Please be consistent regarding terminology: server, AS, RADIUS server > Same remark for client, RADIUS client. > > - > OLD > [RFC6158] recommends three approaches for the transmission of large > amount of data within RADIUS. However, they are not applicable to > the problem statement of this document for the following reasons: > > NEW: > [RFC6158] section 3.1 recommends three approaches for the transmission of large > amount of data within RADIUS. However, they are not applicable to > the problem statement of this document for the following reasons: > > - > OLD > o The first approach does not talk about large ... > > o The second approach is not usable either, ... > > o PMTU discovery does not solve the problem, as it does not allow to > send data larger than the minimum of (PMTU or 4096) octets. > > NEW: > o The first approach (Utilization of a sequence of packets) does not talk about large ... > > o The second approach (Utilization of names rather than values) is not usable either, ... > > o PMTU discovery does not solve the problem, as it does not allow to > send data larger than the minimum of (PMTU or 4096) octets. > > - > Similarly, there is no need to fragment CoA packets. > > A reference, or at least expanding the acronym would help > > - > This limit is the minimum of 4096 octets, and the current PMTU. > I guess you want to say > This limit is the minimum of 4096 octets and the current PMTU. > > - > It is strongly RECOMMENDED that servers include a State attribute > > So strongly RECOMMENDED is between RECOMMENDED and MUST? :-) > Let's not invent new RFC 2119 semantics. > NEW: It is RECOMMENDED that servers include a State attribute > > - Section 4.2 > OLD: Compliant clients receiving this packet will see the Frag-Status > attribute, wand suspend all authorization and authentication handling > until all of the chunks have been received. > > NEW: Compliant clients receiving this packet will see the Frag-Status > attribute,_and_suspend all authorization and authentication handling > until all of the chunks have been received. > > Regarding this sentence, we are in the "post-authorization section". > So shouldn't be: > > NEW: Compliant clients receiving this packet will see the Frag-Status > attribute,_and_suspend all authorization handling > until all of the chunks have been received. > > - Section 11.2 > > The authors acknowledge that this specification violates the "MUST" > requirement of[RFC2865] Section 4.1 . > > Be specific on which MUST requirements in [RFC2865] Section 4.1 > . you refer to > > While you revise the document, you might want to take care of > http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-radext-radius-fragmentation-08.txt > > Regards, Benoit > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------010503060806080203090809 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear Benoit,

thanks for the review. We will prepare a new revision considering your comments.

Best regards,
Alejandro

El 27/11/14 a las 22:31, Benoit Claise escribió:
Dear all,

Here is the AD review.
Note that I initiated a discussion with the IESG on the topic of an experimental doc updating a Standard Track doc. More on this pretty soon (hopefully).

 

1.
Since this is an experimental future RFC, the experiment should be better explained. And if/when the experiment is successful, what's the next step.
As an example, http://tools.ietf.org/html/draft-ietf-radext-dtls-13#section-1.3 was appreciated by the IESG.
Coming back to this draft, if the experiment is success, the Standard Track version will update RFC 2865?

2.
Open question: Does this draft update RFC 6158?
   The Length field in the RADIUS packet header is defined in [RFC2865]
   Section 3.  It is noted there that the maximum length of a RADIUS
   packet is 4096 octets.  As a result, attribute designers SHOULD NOT
   assume that a RADIUS implementation can successfully process RADIUS
   packets larger than 4096 octets.
Or maybe this is taken care of by:
   No such
   exchange is possible for accounting or authorization data.  [RFC6158]
   Section 3.1 suggests that exchanging large amounts authorization data
   is unnecessary in RADIUS.
Or, maybe, if this experiment is successful, then the Standard Track version will update RFC 6158?


Editorial:
-
Your first sentence in the introduction speaks about "Authentication Server (AS)", but some other parts of the document speak about "server"
Example:
   In some cases, however, the
   authorization data sent by the server is large and highly dynamic.
   In other cases, the NAS needs to send large amounts of authorization
   data to the server.
Btw, RFC 6158 speaks of RADIUS Server, which I believe is the right term.
Please be consistent regarding terminology: server, AS, RADIUS server
Same remark for client, RADIUS client.

- 
OLD
 [RFC6158] recommends three approaches for the transmission of large
   amount of data within RADIUS.  However, they are not applicable to
   the problem statement of this document for the following reasons:

NEW:
 [RFC6158] section 3.1 recommends three approaches for the transmission of large
   amount of data within RADIUS.  However, they are not applicable to
   the problem statement of this document for the following reasons:

-
OLD
   o  The first approach does not talk about large ...

   o  The second approach is not usable either, ...

   o  PMTU discovery does not solve the problem, as it does not allow to
      send data larger than the minimum of (PMTU or 4096) octets.

NEW:
   o  The first approach (Utilization of a sequence of packets) does not talk about large ...

   o  The second approach (Utilization of names rather than values) is not usable either, ...

   o  PMTU discovery does not solve the problem, as it does not allow to
      send data larger than the minimum of (PMTU or 4096) octets.

- 
Similarly, there is no need to fragment CoA packets. 

A reference, or at least expanding the acronym would help

-
This limit is the minimum of 4096 octets, and the current PMTU.
I guess you want to say
This limit is the minimum of 4096 octets and the current PMTU.

- 
It is strongly RECOMMENDED that servers include a State attribute

So strongly RECOMMENDED is between RECOMMENDED and MUST? :-)
Let's not invent new RFC 2119 semantics.
NEW: It is RECOMMENDED that servers include a State attribute

- Section 4.2
OLD: Compliant clients receiving this packet will see the Frag-Status
   attribute, wand suspend all authorization and authentication handling
   until all of the chunks have been received. 

NEW: Compliant clients receiving this packet will see the Frag-Status
   attribute, and suspend all authorization and authentication handling
   until all of the chunks have been received.  

Regarding this sentence, we are in the "post-authorization section".
So shouldn't be: 

NEW: Compliant clients receiving this packet will see the Frag-Status
   attribute, and suspend all authorization handling
   until all of the chunks have been received. 

- Section 11.2

 The authors acknowledge that this specification violates the "MUST"
   requirement of [RFC2865] Section 4.1.
Be specific on which MUST requirements in [RFC2865] Section 4.1. you refer to

While you revise the document, you might want to take care of http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-radext-radius-fragmentation-08.txt

Regards, Benoit


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

--------------010503060806080203090809-- From nobody Tue Dec 2 13:50:59 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3219C1A876F; Tue, 2 Dec 2014 13:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJ5vk8EfQlux; Tue, 2 Dec 2014 13:50:51 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id D55701A1B06; Tue, 2 Dec 2014 13:50:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id CC96922403C2; Tue, 2 Dec 2014 22:50: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 prpPauMPPLQs; Tue, 2 Dec 2014 22:50:47 +0100 (CET) Received: from [192.168.20.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 3947522403A6; Tue, 2 Dec 2014 22:50:45 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: <20141202211111.7371.99418.idtracker@ietfa.amsl.com> Date: Tue, 2 Dec 2014 16:50:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141202211111.7371.99418.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/radext/9c3EX-7WveygvXl_hH9OZEEdRts Cc: radext@ietf.org, The IESG , radext-chairs@tools.ietf.org, draft-ietf-radext-nai@tools.ietf.org Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-nai-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 21:50:54 -0000 On Dec 2, 2014, at 4:11 PM, Alissa Cooper wrote: > This document seems to confuse an identifier format with an = identifier, > and I'd like to discuss that. The document defines an identifier format, and then describes how to = use a well-known format to get one identity across multiple protocols. > In my reading, all this document specifies is an identifier format and > length, plus some processing rules for use by AAA systems. It does not > specify the particular contents of the identifier for any specific > protocol or usage, nor does it specify any semantic rules for the > construction of such identifiers (e.g., "the same user should always = use > the same identifier=94). It specifies that the contents of the identifier are: @your.domain.name The domain name has a well-known content, and is defined by the DNS = registry. The =93username=94 portion is under the control of each = domain. We can=92t control how people allocate or manage identifiers in = their own namespace. We *can* require that the identifiers be *recognizable* as = identifiers. > However, the document repeatedly makes the case -- in sections 1, 1.3, > 2.1, 2.7, 2.8 -- that "the NAI" (whether the actual identifier or the > format, it's not clear) should be the universal identifier of choice = for > all situations and protocols, because it "simplifie[s] the management = of > credentials," allows other protocols to "leverage AAA for user > authentication," removes the need to "maintain multiple identifiers = for > one user," etc. The claims in all of these sections seem to conflate a > single user's use of the same identifier with a single user's use of = the > same identifier *format*. I thought what is being defined in this > document is a format and nothing more. I=92m wondering how we can define an identifier format without also = discussing when / where it=92s used. In addition, people are *already* = using one identifier in multiple protocols. How many systems require a = login identifier to be an email address? This document doesn=92t change current practice. It codifies it, and = explains *why* the practice is useful. Section 2.8 makes it clear that the NAI format can be used for = multiple identifiers. There is no requirement that a user has one, and = only one, identifier. > I'm perfectly fine with encouraging the use of a standard format = across > protocols and applications (although I still don't see the need to = repeat > the same recommendation over and over again in the document). That has > basically happened already in lots of places. >=20 > I'm not fine at all with a blanket recommendation to use a single > identifier for the same user everywhere. The document doesn=92t recommend the use of a =93universal=94 = identifier. The Introduction explains the historical practice behind = re-using identifiers: When the NAI was defined for network access, it had the side effect of defining an identifier which could be used in non-AAA systems. Some non-AAA systems defined identifiers which were compatible with the NAI, and deployments used the NAI. This process simplified the management of credentials, by re-using the same credential in multiple situations. This document in no way *requires* each user to have only one = identifier. Instead, it suggests that if you want to use one = =93identifier=94 to identify a user across multiple protocols (as is = widely one today), then that identifier must follow a standard format, = and should be detectable as the same identifier. > The ability to authenticate to > different services (and even to different networks!) using different > identities is a fundamental building block for privacy on the = Internet. > The message from this document seems to be that we should erase that > protection. I disagree completely. I can add text to clarify that if necessary. The document in no way forbids the use of multiple identifiers for one = user. Section 2.8 explicitly allows such practice: It is often useful to create new identifiers for use in specific contexts. Which seems clear to me. > I note that although the stated motivation for this document relates = to > internationalization, pretty much all of the text recommending One > Identifier to Rule Them All is new. So perhaps there were multiple > motivations for this document update? The stated motivations of the document are the real ones. There is no = underhanded motivation to remove internet privacy. Such insinuations are=85 odd, to be polite. > I could offer a bunch of detailed text suggestions, but first I'd like = to > understand what this document is actually trying to do, and whether = the > term "the NAI" is meant to refer to an identifier or an identifier > format.=20 The stated motivations of the document are the overt (and covert) = intentions of the document. To fix errors in RFC 4282. To codify existing practices. To suggest = that use of standard formats is better than ad hoc formats. > =3D Section 2.4 =3D > "Therefore, the utf8-username portion SHOULD be treated > as opaque data when processed by nodes that are not a part of the > authoritative domain (in the sense of Section 4) for that realm." >=20 > What does it mean to treat a cleartext username as opaque data? Should > the nodes outside the realm not log these usernames, or not process = them > in any way? Nodes outside of the realm are free to log anything they wish. The = text is simply a statement that the only *interpretation* of the = =93username=94 portion is=85 that it is a username. It cannot (with any = confidence) be subdivided into fields, or to be interpreted as the name = if a person (it may be only digits). > "Omitting the username part is RECOMMENDED over using a fixed username > part, such as "anonymous", since it provides an unambiguous way to > determine whether the username is intended to uniquely identify a > single user." >=20 > I don't understand why this is true, other than by convention. If I > process a bunch of authentication transactions that use "@example.com" = as > the NAI, how am I supposed to know that each of those was intended to > identify a single user? Is the usage of an NAI to authenticate a group = of > users discussed somewhere? The intent was to discuss EAP methods such as PEAP or TTLS. They = provide for an opaque outer identity: =93anonymous@realm=94, or simply = =93@realm=94. The only purpose of that identity is to allow = intermediate nodes to *route* the traffic. The home node will terminate the EAP / TLS tunnel, and decode the = inner data. That data will contain an NAI which will identify one user = to be authenticated. > In general, I'm uncomfortable with the approach this document takes of > making a few notes about how the username part could be constructed > without providing a more thorough analysis of threats and mitigations > related to identifiability, uniqueness and persistence. Allocation of usernames is something best managed by organizations, = using practices specific to that organization. I see no feasible way = that the IETF can mandate internal organizational behaviour. All we can = do is recommend that the *publicly* visible portions of the identifier = are anonymous. See my suggested text (response to Barry) for details. If the public = face of the NAI is simple =93@realm=94, then there are *no* IETF = activities related to username identifiability, uniqueness, and = persistence. > This also comes > up with the example in Section 2.8, where uniqueness is discussed in = the > context of the example, but there is no generalized discussion about > uniqueness in identifier construction. I fail to see why uniqueness is a consideration. It is perfectly = valid for an organization to re-use the same identifier for multiple = users across time. Or even to simultaneously use the same identifier = for multiple users, with (say) different passwords. The issues of internal organizational management of identifiers is = *completely* outside of the scope of this document. This document = simply specifies the format of an NAI, and how organizations can = exchange data which is associated with a particular NAI. > This might get back to my larger > point above about format versus content -- if this document is just > specifying a format, it probably shouldn't be commenting on the > identifier content It=92s not. The text in 2.8 is an example of how organizations can = use the NAI. It doesn=92t *require* organizations to have any = particular content in the =93username=94 portion. > or the consequences of it (although being able to omit > the username part is certainly a format issue). Only in that there=92s a requirement that the username portion be = omitted, and that requirement affects the format. >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =3D Section 1 =3D > Is dial-up really a prevalent use case to be highlighting first here? = If > we're going to obsolete an old document, it's worth making it current. That text is largely left over from RFC 4282. People still use = dial-up. > Similarly, I wonder how current this text is in Section 1.3? >=20 > "As described in [RFC2194], there are a number of providers offering > network access services, and the number of Internet Service = Providers > involved in roaming consortia is increasing rapidly.=94 Perhaps that could say: As described in [RFC2194], there are a number of providers offering network access services, and essentially all Internet Service = Providers are involved in roaming consortia. From nobody Wed Dec 3 10:16:40 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33381A1BA9; Wed, 3 Dec 2014 10:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0b8ONOpL8uyY; Wed, 3 Dec 2014 10:16:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E81BE1A89E1; Wed, 3 Dec 2014 10:16:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141203181625.31914.28779.idtracker@ietfa.amsl.com> Date: Wed, 03 Dec 2014 10:16:25 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/apU9CUZ-U2YZ5PduCXLsyWHM4PU Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-nai-12.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 18:16:28 -0000 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 : The Network Access Identifier Author : Alan DeKok Filename : draft-ietf-radext-nai-12.txt Pages : 29 Date : 2014-12-03 Abstract: In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282, 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 3 21:13:37 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E2A1ACF6A for ; Wed, 3 Dec 2014 16:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnE420l1STF3 for ; Wed, 3 Dec 2014 16:10:48 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB1E1ACF6E for ; Wed, 3 Dec 2014 16:10:46 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1147B20980 for ; Wed, 3 Dec 2014 19:10:45 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 03 Dec 2014 19:10:45 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=ldAc7WB3z1xoxjjingiy3SGVBMY=; b=pMSXj1DNkrnDQIO8dsL/L FBAZS1iitZmJrtE03p/tQ23YRVZcT4jU2Mu1ASJ5DYcj/WNdH3lx8+DUiny2eNwp UC18OS4loxuv0M5kygaI3bWkhMm0GL8y1Xfxo1G7NbyIRcMKXejq1nF/cPe2fuse JgvDv0XEZApsIGuEmmob6g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=ldAc7WB3z1xoxjjingiy3SG VBMY=; b=D6HK/R9V3vjlIo/d7a1bEcSz9cOi04n/UTmxM1+y60XbAirSep90idS Ngss5YmiabdMrusOEU3I8WF/JRn4k29NsHCDRRm+S4eAt8AyHGCQdMAcuUpIolgZ D8dmVkZ60hdFhukm/aeh3W6O4u2Ssm75czwUUoYvXhOaHR7RpShk= X-Sasl-enc: IFLMywIaNqxW/DkIAFThjgqqOKat/xHKYwnGlZ0YSMB/ 1417651844 Received: from [10.35.132.83] (unknown [128.107.239.235]) by mail.messagingengine.com (Postfix) with ESMTPA id 15803C0027E; Wed, 3 Dec 2014 19:10:43 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Wed, 3 Dec 2014 16:11:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2C199F64-7CEF-4ECB-B6AE-D280E30829F7@cooperw.in> References: <20141202211111.7371.99418.idtracker@ietfa.amsl.com> To: Alan DeKok X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/radext/KLC-Ekvc3tHOmxYY0f4ZyVaegxM X-Mailman-Approved-At: Wed, 03 Dec 2014 21:13:34 -0800 Cc: radext@ietf.org, IESG , radext-chairs@tools.ietf.org, draft-ietf-radext-nai@tools.ietf.org Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-nai-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 00:10:54 -0000 Hi Alan, Thanks. I think I have a little more clarity now, so I=92ll try to make = some suggestions that are in line with your responses. It seems that = =93NAI=94 is used interchangeably to describe both the format and a = specific use of an identifier, so a lot of my suggestions aim to = increase the clarity about the distinction between the two. =3D Section 1 =3D s/a standardized method for identifying users/a standardized user = identifier format/ OLD We suggest that this re-use is good practice, so long as privacy issues are dealt with. The alternative is to have protocol-specific identifiers, which increases cost to both the user and the administrator. NEW Protocols that re-use the same credential or the same identifier format = can benefit from this management simplicity. The alternative is to have = protocol-specific credentials or identifier formats, which increases = cost to both the user and the administrator. [If protocols require credential re-use, I=92m not sure what it means = for the privacy issues to be dealt with.] OLD We hope to encourage the wide-spread adoption of the NAI as an = identifier. This adoption will decrease work required to leverage = identification and authentication in other protocols. NEW We hope to encourage the wide-spread adoption of the NAI format. This = adoption can help decrease work required to leverage identification and = authentication across protocols. s/only suggest that the NAI be used/only suggest that the NAI format be = used/ =3D Section 1.3 =3D s/can take advantage of the NAI/can take advantage of the NAI format/ s/definition of a user identifier/definition of a user identifier = format/ s/It is hoped that the NAI is a user identifier/It is hoped that the NAI = is a user identifier format/ s/identifier is itself kept private/identifier is itself protected = against unauthorized access/ [wasn=92t sure what was meant by =93kept private=94] =3D Section 1.4 =3D I would suggest that either the title of this section be changed to = =93Motivation Related to Internationalization Concerns=94 or the = following text (based on your response below) be added to the final = paragraph in the section: Furthermore, this document was motivated by a desire to codify existing = practice related to the use of the NAI format and to encourage = widespread use of the format. =3D Section 2.1 =3D s/which is a user identifier/which is a user identifier format/ =3D Section 2.4 =3D Thanks for the new text here, it=92s very helpful.=20 OLD since it provides an unambiguous way to determine whether the username is intended to uniquely identify a single user. NEW since including a fixed username part is ambiguous as to whether the NAI = refers to a single user or not. s/use-case of such behavior/use case of omitting or obfuscating the = username part/ s/user privacy is preserved/the username part is kept confidential from = the visited network/ =3D Section 2.7 =3D s/the NAI MAY be used in other/the NAI format MAY be used in other/ OLD It is RECOMMENDED that protocols requiring the use of a user identifier reference this specification, and suggest that the use of an NAI is RECOMMENDED. NEW It is RECOMMENDED that protocols requiring the use of a user identifier use the NAI format. [ISTM that some protocols will have the specific identifier format as = REQUIRED, so it seems awkward to suggest that they all make it a = RECOMMENDED.] s/to use the NAI/to use the NAI format/ s/This format ensures/The format as defined by 3GPP ensures/ "It is RECOMMENDED that methods similar to that described above for 3GPP = be used to derive the identifier.=94 Pulling up our discussion from earlier in the thread: >> This also comes >> up with the example in Section 2.8, where uniqueness is discussed in = the >> context of the example, but there is no generalized discussion about >> uniqueness in identifier construction. >=20 > I fail to see why uniqueness is a consideration. It is perfectly = valid for an organization to re-use the same identifier for multiple = users across time. Or even to simultaneously use the same identifier = for multiple users, with (say) different passwords. >=20 > The issues of internal organizational management of identifiers is = *completely* outside of the scope of this document. This document = simply specifies the format of an NAI, and how organizations can = exchange data which is associated with a particular NAI. >=20 >> This might get back to my larger >> point above about format versus content -- if this document is just >> specifying a format, it probably shouldn't be commenting on the >> identifier content >=20 > It=92s not. The text in 2.8 is an example of how organizations can = use the NAI. It doesn=92t *require* organizations to have any = particular content in the =93username=94 portion. If the 3GPP example is just an example, why is there a recommendation = that identifiers used in all new specifications and protocols be = constructed according to the same methods used to construct the 3GPP = identifiers (including the requirement that the username part be in a = well-known format)? =3D Section 3 =3D s/similar in format to the NAI/similar in format to the NAI format/ =3D Section 4 =3D=20 The new text is very helpful, thanks. =3D Section 4.2 =3D It seems that the problem described here is not one of using multiple = identifier formats, but using multiple identifiers. So it seems slightly = different from what was described in 1.3. Best, Alissa On Dec 2, 2014, at 1:50 PM, Alan DeKok = wrote: > On Dec 2, 2014, at 4:11 PM, Alissa Cooper wrote: >> This document seems to confuse an identifier format with an = identifier, >> and I'd like to discuss that. >=20 > The document defines an identifier format, and then describes how to = use a well-known format to get one identity across multiple protocols. >=20 >> In my reading, all this document specifies is an identifier format = and >> length, plus some processing rules for use by AAA systems. It does = not >> specify the particular contents of the identifier for any specific >> protocol or usage, nor does it specify any semantic rules for the >> construction of such identifiers (e.g., "the same user should always = use >> the same identifier=94). >=20 > It specifies that the contents of the identifier are: >=20 > @your.domain.name >=20 > The domain name has a well-known content, and is defined by the DNS = registry. The =93username=94 portion is under the control of each = domain. We can=92t control how people allocate or manage identifiers in = their own namespace. >=20 > We *can* require that the identifiers be *recognizable* as = identifiers. >=20 >> However, the document repeatedly makes the case -- in sections 1, = 1.3, >> 2.1, 2.7, 2.8 -- that "the NAI" (whether the actual identifier or the >> format, it's not clear) should be the universal identifier of choice = for >> all situations and protocols, because it "simplifie[s] the management = of >> credentials," allows other protocols to "leverage AAA for user >> authentication," removes the need to "maintain multiple identifiers = for >> one user," etc. The claims in all of these sections seem to conflate = a >> single user's use of the same identifier with a single user's use of = the >> same identifier *format*. I thought what is being defined in this >> document is a format and nothing more. >=20 > I=92m wondering how we can define an identifier format without also = discussing when / where it=92s used. In addition, people are *already* = using one identifier in multiple protocols. How many systems require a = login identifier to be an email address? >=20 > This document doesn=92t change current practice. It codifies it, and = explains *why* the practice is useful. >=20 > Section 2.8 makes it clear that the NAI format can be used for = multiple identifiers. There is no requirement that a user has one, and = only one, identifier. >=20 >> I'm perfectly fine with encouraging the use of a standard format = across >> protocols and applications (although I still don't see the need to = repeat >> the same recommendation over and over again in the document). That = has >> basically happened already in lots of places. >>=20 >> I'm not fine at all with a blanket recommendation to use a single >> identifier for the same user everywhere. >=20 > The document doesn=92t recommend the use of a =93universal=94 = identifier. The Introduction explains the historical practice behind = re-using identifiers: >=20 > When the NAI was defined for network access, it had the side effect of > defining an identifier which could be used in non-AAA systems. Some > non-AAA systems defined identifiers which were compatible with the > NAI, and deployments used the NAI. This process simplified the > management of credentials, by re-using the same credential in multiple > situations. >=20 > This document in no way *requires* each user to have only one = identifier. Instead, it suggests that if you want to use one = =93identifier=94 to identify a user across multiple protocols (as is = widely one today), then that identifier must follow a standard format, = and should be detectable as the same identifier. >=20 >> The ability to authenticate to >> different services (and even to different networks!) using different >> identities is a fundamental building block for privacy on the = Internet. >> The message from this document seems to be that we should erase that >> protection. >=20 > I disagree completely. I can add text to clarify that if necessary. >=20 > The document in no way forbids the use of multiple identifiers for = one user. Section 2.8 explicitly allows such practice: >=20 > It is often useful to create new identifiers for use in specific > contexts. >=20 > Which seems clear to me. >=20 >> I note that although the stated motivation for this document relates = to >> internationalization, pretty much all of the text recommending One >> Identifier to Rule Them All is new. So perhaps there were multiple >> motivations for this document update? >=20 > The stated motivations of the document are the real ones. There is = no underhanded motivation to remove internet privacy. >=20 > Such insinuations are=85 odd, to be polite. >=20 >> I could offer a bunch of detailed text suggestions, but first I'd = like to >> understand what this document is actually trying to do, and whether = the >> term "the NAI" is meant to refer to an identifier or an identifier >> format.=20 >=20 > The stated motivations of the document are the overt (and covert) = intentions of the document. >=20 > To fix errors in RFC 4282. To codify existing practices. To suggest = that use of standard formats is better than ad hoc formats. >=20 >=20 >> "Omitting the username part is RECOMMENDED over using a fixed = username >> part, such as "anonymous", since it provides an unambiguous way to >> determine whether the username is intended to uniquely identify a >> single user." >>=20 >> I don't understand why this is true, other than by convention. If I >> process a bunch of authentication transactions that use = "@example.com" as >> the NAI, how am I supposed to know that each of those was intended to >> identify a single user? Is the usage of an NAI to authenticate a = group of >> users discussed somewhere? >=20 > The intent was to discuss EAP methods such as PEAP or TTLS. They = provide for an opaque outer identity: =93anonymous@realm=94, or simply = =93@realm=94. The only purpose of that identity is to allow = intermediate nodes to *route* the traffic. >=20 > The home node will terminate the EAP / TLS tunnel, and decode the = inner data. That data will contain an NAI which will identify one user = to be authenticated. >=20 >> In general, I'm uncomfortable with the approach this document takes = of >> making a few notes about how the username part could be constructed >> without providing a more thorough analysis of threats and mitigations >> related to identifiability, uniqueness and persistence. >=20 > Allocation of usernames is something best managed by organizations, = using practices specific to that organization. I see no feasible way = that the IETF can mandate internal organizational behaviour. All we can = do is recommend that the *publicly* visible portions of the identifier = are anonymous. >=20 > See my suggested text (response to Barry) for details. If the public = face of the NAI is simple =93@realm=94, then there are *no* IETF = activities related to username identifiability, uniqueness, and = persistence. >=20 >>=20 >=20 >> or the consequences of it (although being able to omit >> the username part is certainly a format issue). >=20 > Only in that there=92s a requirement that the username portion be = omitted, and that requirement affects the format. >=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> =3D Section 1 =3D >> Is dial-up really a prevalent use case to be highlighting first here? = If >> we're going to obsolete an old document, it's worth making it = current. >=20 > That text is largely left over from RFC 4282. People still use = dial-up. >=20 >> Similarly, I wonder how current this text is in Section 1.3? >>=20 >> "As described in [RFC2194], there are a number of providers offering >> network access services, and the number of Internet Service = Providers >> involved in roaming consortia is increasing rapidly.=94 >=20 > Perhaps that could say: >=20 > As described in [RFC2194], there are a number of providers offering > network access services, and essentially all Internet Service = Providers > are involved in roaming consortia. From nobody Wed Dec 3 21:13:39 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861081A6FCF; Wed, 3 Dec 2014 17:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPJElC-FFoeZ; Wed, 3 Dec 2014 17:03:43 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8B01A1A5E; Wed, 3 Dec 2014 17:03:42 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id hv19so8963256lab.28 for ; Wed, 03 Dec 2014 17:03:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GJHDlQLrHVQg2u8ox2a1eQmbRNweAjNTBzobEYS5r4Y=; b=lKD6Qj3lqmuk3xEyL3xslG18nlep5/3qV8zTdjzlCMEDfZ84sJeFX4qEgeFhg7UzKZ ncqQHKiBlc0q7CYdjScHmozOVfhXh1oYZCX6q93MsDIaULCzqncjYdA5D6UgKPw9HULs OnakA6kRdixLgKFwEh0iDkGkewHwj4N+/qv5pzxWkViXPISZ64axGx8AVSPqo1aUAkkB gHLO8+RBIU5kE5QDV0KqtWOIj1e1TcvdnQsDA9+yrdelXWI1x05cxZ9moZaxgy6e1FpT GFYnpxuTAVmEQniednqjcQ+WnYN7bdUkQGo55va2FI7zcM1dlTZNbJgIbaW0ZCjaZUQG 2j+w== MIME-Version: 1.0 X-Received: by 10.112.73.102 with SMTP id k6mr6693496lbv.75.1417655021240; Wed, 03 Dec 2014 17:03:41 -0800 (PST) Received: by 10.112.49.52 with HTTP; Wed, 3 Dec 2014 17:03:41 -0800 (PST) In-Reply-To: <3A63E957-5831-4A95-A739-1D7B365ACCBA@cooperw.in> References: <2C199F64-7CEF-4ECB-B6AE-D280E30829F7@cooperw.in> <3A63E957-5831-4A95-A739-1D7B365ACCBA@cooperw.in> Date: Wed, 3 Dec 2014 20:03:41 -0500 Message-ID: From: Kathleen Moriarty To: aland@freeradius.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/radext/e2aw_t8CvhJO3mONwU0NavCnuMM X-Mailman-Approved-At: Wed, 03 Dec 2014 21:13:33 -0800 Cc: radext@ietf.org, The IESG , radext-chairs@tools.ietf.org, draft-ietf-radext-nai@tools.ietf.org Subject: [radext] Fwd: Alissa Cooper's Discuss on draft-ietf-radext-nai-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 01:03:52 -0000 Forwarding for Alyssa, she is having some trouble with email to iesg@ietf.o= rg. ---------- Forwarded message ---------- From: Alissa Cooper Date: Wed, Dec 3, 2014 at 8:01 PM Subject: Fwd: Alissa Cooper's Discuss on draft-ietf-radext-nai-11: (with DISCUSS and COMMENT) To: Kathleen Moriarty Begin forwarded message: From: Alissa Cooper Subject: Re: Alissa Cooper's Discuss on draft-ietf-radext-nai-11: (with DISCUSS and COMMENT) Date: December 3, 2014 at 4:11:04 PM PST To: Alan DeKok Cc: IESG , radext-chairs@tools.ietf.org, draft-ietf-radext-nai@tools.ietf.org, radext@ietf.org Hi Alan, Thanks. I think I have a little more clarity now, so I=E2=80=99ll try to ma= ke some suggestions that are in line with your responses. It seems that =E2=80=9CNAI=E2=80=9D is used interchangeably to describe both the format a= nd a specific use of an identifier, so a lot of my suggestions aim to increase the clarity about the distinction between the two. =3D Section 1 =3D s/a standardized method for identifying users/a standardized user identifier format/ OLD We suggest that this re-use is good practice, so long as privacy issues are dealt with. The alternative is to have protocol-specific identifiers, which increases cost to both the user and the administrator. NEW Protocols that re-use the same credential or the same identifier format can benefit from this management simplicity. The alternative is to have protocol-specific credentials or identifier formats, which increases cost to both the user and the administrator. [If protocols require credential re-use, I=E2=80=99m not sure what it means for the privacy issues to be dealt with.] OLD We hope to encourage the wide-spread adoption of the NAI as an identifier. This adoption will decrease work required to leverage identification and authentication in other protocols. NEW We hope to encourage the wide-spread adoption of the NAI format. This adoption can help decrease work required to leverage identification and authentication across protocols. s/only suggest that the NAI be used/only suggest that the NAI format be use= d/ =3D Section 1.3 =3D s/can take advantage of the NAI/can take advantage of the NAI format/ s/definition of a user identifier/definition of a user identifier format/ s/It is hoped that the NAI is a user identifier/It is hoped that the NAI is a user identifier format/ s/identifier is itself kept private/identifier is itself protected against unauthorized access/ [wasn=E2=80=99t sure what was meant by =E2=80=9Ckept private=E2=80=9D] =3D Section 1.4 =3D I would suggest that either the title of this section be changed to =E2=80=9CMotivation Related to Internationalization Concerns=E2=80=9D or th= e following text (based on your response below) be added to the final paragraph in the section: Furthermore, this document was motivated by a desire to codify existing practice related to the use of the NAI format and to encourage widespread use of the format. =3D Section 2.1 =3D s/which is a user identifier/which is a user identifier format/ =3D Section 2.4 =3D Thanks for the new text here, it=E2=80=99s very helpful. OLD since it provides an unambiguous way to determine whether the username is intended to uniquely identify a single user. NEW since including a fixed username part is ambiguous as to whether the NAI refers to a single user or not. s/use-case of such behavior/use case of omitting or obfuscating the username part/ s/user privacy is preserved/the username part is kept confidential from the visited network/ =3D Section 2.7 =3D s/the NAI MAY be used in other/the NAI format MAY be used in other/ OLD It is RECOMMENDED that protocols requiring the use of a user identifier reference this specification, and suggest that the use of an NAI is RECOMMENDED. NEW It is RECOMMENDED that protocols requiring the use of a user identifier use the NAI format. [ISTM that some protocols will have the specific identifier format as REQUIRED, so it seems awkward to suggest that they all make it a RECOMMENDED.] s/to use the NAI/to use the NAI format/ s/This format ensures/The format as defined by 3GPP ensures/ "It is RECOMMENDED that methods similar to that described above for 3GPP be used to derive the identifier.=E2=80=9D Pulling up our discussion from earlier in the thread: This also comes up with the example in Section 2.8, where uniqueness is discussed in the context of the example, but there is no generalized discussion about uniqueness in identifier construction. I fail to see why uniqueness is a consideration. It is perfectly valid for an organization to re-use the same identifier for multiple users across time. Or even to simultaneously use the same identifier for multiple users, with (say) different passwords. The issues of internal organizational management of identifiers is *completely* outside of the scope of this document. This document simply specifies the format of an NAI, and how organizations can exchange data which is associated with a particular NAI. This might get back to my larger point above about format versus content -- if this document is just specifying a format, it probably shouldn't be commenting on the identifier content It=E2=80=99s not. The text in 2.8 is an example of how organizations can u= se the NAI. It doesn=E2=80=99t *require* organizations to have any particular content in the =E2=80=9Cusername=E2=80=9D portion. If the 3GPP example is just an example, why is there a recommendation that identifiers used in all new specifications and protocols be constructed according to the same methods used to construct the 3GPP identifiers (including the requirement that the username part be in a well-known format)? =3D Section 3 =3D s/similar in format to the NAI/similar in format to the NAI format/ =3D Section 4 =3D The new text is very helpful, thanks. =3D Section 4.2 =3D It seems that the problem described here is not one of using multiple identifier formats, but using multiple identifiers. So it seems slightly different from what was described in 1.3. Best, Alissa On Dec 2, 2014, at 1:50 PM, Alan DeKok wrote: On Dec 2, 2014, at 4:11 PM, Alissa Cooper wrote: This document seems to confuse an identifier format with an identifier, and I'd like to discuss that. The document defines an identifier format, and then describes how to use a well-known format to get one identity across multiple protocols. In my reading, all this document specifies is an identifier format and length, plus some processing rules for use by AAA systems. It does not specify the particular contents of the identifier for any specific protocol or usage, nor does it specify any semantic rules for the construction of such identifiers (e.g., "the same user should always use the same identifier=E2=80=9D). It specifies that the contents of the identifier are: @your.domain.name The domain name has a well-known content, and is defined by the DNS registry. The =E2=80=9Cusername=E2=80=9D portion is under the control of e= ach domain. We can=E2=80=99t control how people allocate or manage identifiers in their own namespace. We *can* require that the identifiers be *recognizable* as identifiers. However, the document repeatedly makes the case -- in sections 1, 1.3, 2.1, 2.7, 2.8 -- that "the NAI" (whether the actual identifier or the format, it's not clear) should be the universal identifier of choice for all situations and protocols, because it "simplifie[s] the management of credentials," allows other protocols to "leverage AAA for user authentication," removes the need to "maintain multiple identifiers for one user," etc. The claims in all of these sections seem to conflate a single user's use of the same identifier with a single user's use of the same identifier *format*. I thought what is being defined in this document is a format and nothing more. I=E2=80=99m wondering how we can define an identifier format without also discussing when / where it=E2=80=99s used. In addition, people are *alread= y* using one identifier in multiple protocols. How many systems require a login identifier to be an email address? This document doesn=E2=80=99t change current practice. It codifies it, and explains *why* the practice is useful. Section 2.8 makes it clear that the NAI format can be used for multiple identifiers. There is no requirement that a user has one, and only one, identifier. I'm perfectly fine with encouraging the use of a standard format across protocols and applications (although I still don't see the need to repeat the same recommendation over and over again in the document). That has basically happened already in lots of places. I'm not fine at all with a blanket recommendation to use a single identifier for the same user everywhere. The document doesn=E2=80=99t recommend the use of a =E2=80=9Cuniversal=E2= =80=9D identifier. The Introduction explains the historical practice behind re-using identifiers: When the NAI was defined for network access, it had the side effect of defining an identifier which could be used in non-AAA systems. Some non-AAA systems defined identifiers which were compatible with the NAI, and deployments used the NAI. This process simplified the management of credentials, by re-using the same credential in multiple situations. This document in no way *requires* each user to have only one identifier. Instead, it suggests that if you want to use one =E2=80=9Cidentifier=E2=80=9D to identify a user across multiple protocols (= as is widely one today), then that identifier must follow a standard format, and should be detectable as the same identifier. The ability to authenticate to different services (and even to different networks!) using different identities is a fundamental building block for privacy on the Internet. The message from this document seems to be that we should erase that protection. I disagree completely. I can add text to clarify that if necessary. The document in no way forbids the use of multiple identifiers for one user. Section 2.8 explicitly allows such practice: It is often useful to create new identifiers for use in specific contexts. Which seems clear to me. I note that although the stated motivation for this document relates to internationalization, pretty much all of the text recommending One Identifier to Rule Them All is new. So perhaps there were multiple motivations for this document update? The stated motivations of the document are the real ones. There is no underhanded motivation to remove internet privacy. Such insinuations are=E2=80=A6 odd, to be polite. I could offer a bunch of detailed text suggestions, but first I'd like to understand what this document is actually trying to do, and whether the term "the NAI" is meant to refer to an identifier or an identifier format. The stated motivations of the document are the overt (and covert) intentions of the document. To fix errors in RFC 4282. To codify existing practices. To suggest that use of standard formats is better than ad hoc formats. "Omitting the username part is RECOMMENDED over using a fixed username part, such as "anonymous", since it provides an unambiguous way to determine whether the username is intended to uniquely identify a single user." I don't understand why this is true, other than by convention. If I process a bunch of authentication transactions that use "@example.com" as the NAI, how am I supposed to know that each of those was intended to identify a single user? Is the usage of an NAI to authenticate a group of users discussed somewhere? The intent was to discuss EAP methods such as PEAP or TTLS. They provide for an opaque outer identity: =E2=80=9Canonymous@realm=E2=80=9D, or= simply =E2=80=9C@realm=E2=80=9D. The only purpose of that identity is to allow in= termediate nodes to *route* the traffic. The home node will terminate the EAP / TLS tunnel, and decode the inner data. That data will contain an NAI which will identify one user to be authenticated. In general, I'm uncomfortable with the approach this document takes of making a few notes about how the username part could be constructed without providing a more thorough analysis of threats and mitigations related to identifiability, uniqueness and persistence. Allocation of usernames is something best managed by organizations, using practices specific to that organization. I see no feasible way that the IETF can mandate internal organizational behaviour. All we can do is recommend that the *publicly* visible portions of the identifier are anonymous. See my suggested text (response to Barry) for details. If the public face of the NAI is simple =E2=80=9C@realm=E2=80=9D, then there are *no* IET= F activities related to username identifiability, uniqueness, and persistence. or the consequences of it (although being able to omit the username part is certainly a format issue). Only in that there=E2=80=99s a requirement that the username portion be omitted, and that requirement affects the format. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =3D Section 1 =3D Is dial-up really a prevalent use case to be highlighting first here? If we're going to obsolete an old document, it's worth making it current. That text is largely left over from RFC 4282. People still use dial-up. Similarly, I wonder how current this text is in Section 1.3? "As described in [RFC2194], there are a number of providers offering network access services, and the number of Internet Service Providers involved in roaming consortia is increasing rapidly.=E2=80=9D Perhaps that could say: As described in [RFC2194], there are a number of providers offering network access services, and essentially all Internet Service Providers are involved in roaming consortia. --=20 Best regards, Kathleen From nobody Thu Dec 4 03:38:44 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DB61A023E; Thu, 4 Dec 2014 03:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUDRIqLaLDv7; Thu, 4 Dec 2014 03:38:34 -0800 (PST) Received: from bgl-iport-3.cisco.com (bgl-iport-3.cisco.com [72.163.197.27]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D841A0271; Thu, 4 Dec 2014 03:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14088; q=dns/txt; s=iport; t=1417693113; x=1418902713; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Bc6JiQPt+K1u1kDy0NSTgvU58huiJ+s6u5r4s/q4Go4=; b=aCelg5pZuGlKyqzZpscsVEQsonIBa/4IECxnwqpRRdzLhC18kBdIwt6N eGzlhIoWy45WUDAsnfyEuwAtyJFDpVm9dFSsNJghhtTWS+pEm0o9L64WY tWVZL6wLGIlnIuIYYJ5pHCo4LHys8KTdQA3Ag+XHY8TF2ToHH5No6jIpE I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEACxHgFRIo8UY/2dsb2JhbABQAQmDWFi9CIlHhhoCgTABAQEBAX2EAgEBAQMBMgEFQAEFCwsYCQ0BCA8JAwIBAgFFBgEMAQMCAgEBiDEJ1jwBAQEBAQEEAQEBAQEBAQEBAQEXilqFKgYBCgEdMwcSAYQvAQSFaY49g3uCOYEiOIVChiKCcINpgX43gUU+BCyBBQcXgSIBAQE X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="13593777" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-3.cisco.com with ESMTP; 04 Dec 2014 11:38:28 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sB4BcELL018433; Thu, 4 Dec 2014 11:38:18 GMT Message-ID: <548047A5.5020103@cisco.com> Date: Thu, 04 Dec 2014 12:38:13 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Alissa Cooper , Alan DeKok References: <20141202211111.7371.99418.idtracker@ietfa.amsl.com> <2C199F64-7CEF-4ECB-B6AE-D280E30829F7@cooperw.in> In-Reply-To: <2C199F64-7CEF-4ECB-B6AE-D280E30829F7@cooperw.in> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/Jy14tC8WW4rpKw_uqrJFDg4vDVM Cc: radext@ietf.org, IESG , radext-chairs@tools.ietf.org, draft-ietf-radext-nai@tools.ietf.org Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-nai-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 11:38:39 -0000 Thanks Alissa for the suggestions. This clarifies the document. Regards, Benoit > Hi Alan, > > Thanks. I think I have a little more clarity now, so I’ll try to make some suggestions that are in line with your responses. It seems that “NAI” is used interchangeably to describe both the format and a specific use of an identifier, so a lot of my suggestions aim to increase the clarity about the distinction between the two. > > = Section 1 = > s/a standardized method for identifying users/a standardized user identifier format/ > > OLD > We suggest that this re-use is good practice, > so long as privacy issues are dealt with. The alternative is to have > protocol-specific identifiers, which increases cost to both the user > and the administrator. > > NEW > Protocols that re-use the same credential or the same identifier format can benefit from this management simplicity. The alternative is to have protocol-specific credentials or identifier formats, which increases cost to both the user and the administrator. > > [If protocols require credential re-use, I’m not sure what it means for the privacy issues to be dealt with.] > > OLD > We hope to encourage the wide-spread adoption of the NAI as an identifier. This adoption will decrease work required to leverage identification and authentication in other protocols. > > NEW > We hope to encourage the wide-spread adoption of the NAI format. This adoption can help decrease work required to leverage identification and authentication across protocols. > > s/only suggest that the NAI be used/only suggest that the NAI format be used/ > > = Section 1.3 = > s/can take advantage of the NAI/can take advantage of the NAI format/ > > s/definition of a user identifier/definition of a user identifier format/ > > s/It is hoped that the NAI is a user identifier/It is hoped that the NAI is a user identifier format/ > > s/identifier is itself kept private/identifier is itself protected against unauthorized access/ > [wasn’t sure what was meant by “kept private”] > > = Section 1.4 = > I would suggest that either the title of this section be changed to “Motivation Related to Internationalization Concerns” or the following text (based on your response below) be added to the final paragraph in the section: > > Furthermore, this document was motivated by a desire to codify existing practice related to the use of the NAI format and to encourage widespread use of the format. > > = Section 2.1 = > s/which is a user identifier/which is a user identifier format/ > > = Section 2.4 = > Thanks for the new text here, it’s very helpful. > > OLD > since it provides an unambiguous way to > determine whether the username is intended to uniquely identify a > single user. > > NEW > since including a fixed username part is ambiguous as to whether the NAI refers to a single user or not. > > s/use-case of such behavior/use case of omitting or obfuscating the username part/ > > s/user privacy is preserved/the username part is kept confidential from the visited network/ > > = Section 2.7 = > s/the NAI MAY be used in other/the NAI format MAY be used in other/ > > OLD > It is RECOMMENDED that protocols requiring the use of > a user identifier reference this specification, and suggest that the > use of an NAI is RECOMMENDED. > > NEW > It is RECOMMENDED that protocols requiring the use of > a user identifier use the NAI format. > > [ISTM that some protocols will have the specific identifier format as REQUIRED, so it seems awkward to suggest that they all make it a RECOMMENDED.] > > s/to use the NAI/to use the NAI format/ > > s/This format ensures/The format as defined by 3GPP ensures/ > > "It is RECOMMENDED that methods similar to that described above for 3GPP be > used to derive the identifier.” > > Pulling up our discussion from earlier in the thread: > >>> This also comes >>> up with the example in Section 2.8, where uniqueness is discussed in the >>> context of the example, but there is no generalized discussion about >>> uniqueness in identifier construction. >> I fail to see why uniqueness is a consideration. It is perfectly valid for an organization to re-use the same identifier for multiple users across time. Or even to simultaneously use the same identifier for multiple users, with (say) different passwords. >> >> The issues of internal organizational management of identifiers is *completely* outside of the scope of this document. This document simply specifies the format of an NAI, and how organizations can exchange data which is associated with a particular NAI. >> >>> This might get back to my larger >>> point above about format versus content -- if this document is just >>> specifying a format, it probably shouldn't be commenting on the >>> identifier content >> It’s not. The text in 2.8 is an example of how organizations can use the NAI. It doesn’t *require* organizations to have any particular content in the “username” portion. > If the 3GPP example is just an example, why is there a recommendation that identifiers used in all new specifications and protocols be constructed according to the same methods used to construct the 3GPP identifiers (including the requirement that the username part be in a well-known format)? > > = Section 3 = > s/similar in format to the NAI/similar in format to the NAI format/ > > = Section 4 = > The new text is very helpful, thanks. > > = Section 4.2 = > It seems that the problem described here is not one of using multiple identifier formats, but using multiple identifiers. So it seems slightly different from what was described in 1.3. > > Best, > Alissa > > On Dec 2, 2014, at 1:50 PM, Alan DeKok wrote: > >> On Dec 2, 2014, at 4:11 PM, Alissa Cooper wrote: >>> This document seems to confuse an identifier format with an identifier, >>> and I'd like to discuss that. >> The document defines an identifier format, and then describes how to use a well-known format to get one identity across multiple protocols. >> >>> In my reading, all this document specifies is an identifier format and >>> length, plus some processing rules for use by AAA systems. It does not >>> specify the particular contents of the identifier for any specific >>> protocol or usage, nor does it specify any semantic rules for the >>> construction of such identifiers (e.g., "the same user should always use >>> the same identifier”). >> It specifies that the contents of the identifier are: >> >> @your.domain.name >> >> The domain name has a well-known content, and is defined by the DNS registry. The “username” portion is under the control of each domain. We can’t control how people allocate or manage identifiers in their own namespace. >> >> We *can* require that the identifiers be *recognizable* as identifiers. >> >>> However, the document repeatedly makes the case -- in sections 1, 1.3, >>> 2.1, 2.7, 2.8 -- that "the NAI" (whether the actual identifier or the >>> format, it's not clear) should be the universal identifier of choice for >>> all situations and protocols, because it "simplifie[s] the management of >>> credentials," allows other protocols to "leverage AAA for user >>> authentication," removes the need to "maintain multiple identifiers for >>> one user," etc. The claims in all of these sections seem to conflate a >>> single user's use of the same identifier with a single user's use of the >>> same identifier *format*. I thought what is being defined in this >>> document is a format and nothing more. >> I’m wondering how we can define an identifier format without also discussing when / where it’s used. In addition, people are *already* using one identifier in multiple protocols. How many systems require a login identifier to be an email address? >> >> This document doesn’t change current practice. It codifies it, and explains *why* the practice is useful. >> >> Section 2.8 makes it clear that the NAI format can be used for multiple identifiers. There is no requirement that a user has one, and only one, identifier. >> >>> I'm perfectly fine with encouraging the use of a standard format across >>> protocols and applications (although I still don't see the need to repeat >>> the same recommendation over and over again in the document). That has >>> basically happened already in lots of places. >>> >>> I'm not fine at all with a blanket recommendation to use a single >>> identifier for the same user everywhere. >> The document doesn’t recommend the use of a “universal” identifier. The Introduction explains the historical practice behind re-using identifiers: >> >> When the NAI was defined for network access, it had the side effect of >> defining an identifier which could be used in non-AAA systems. Some >> non-AAA systems defined identifiers which were compatible with the >> NAI, and deployments used the NAI. This process simplified the >> management of credentials, by re-using the same credential in multiple >> situations. >> >> This document in no way *requires* each user to have only one identifier. Instead, it suggests that if you want to use one “identifier” to identify a user across multiple protocols (as is widely one today), then that identifier must follow a standard format, and should be detectable as the same identifier. >> >>> The ability to authenticate to >>> different services (and even to different networks!) using different >>> identities is a fundamental building block for privacy on the Internet. >>> The message from this document seems to be that we should erase that >>> protection. >> I disagree completely. I can add text to clarify that if necessary. >> >> The document in no way forbids the use of multiple identifiers for one user. Section 2.8 explicitly allows such practice: >> >> It is often useful to create new identifiers for use in specific >> contexts. >> >> Which seems clear to me. >> >>> I note that although the stated motivation for this document relates to >>> internationalization, pretty much all of the text recommending One >>> Identifier to Rule Them All is new. So perhaps there were multiple >>> motivations for this document update? >> The stated motivations of the document are the real ones. There is no underhanded motivation to remove internet privacy. >> >> Such insinuations are… odd, to be polite. >> >>> I could offer a bunch of detailed text suggestions, but first I'd like to >>> understand what this document is actually trying to do, and whether the >>> term "the NAI" is meant to refer to an identifier or an identifier >>> format. >> The stated motivations of the document are the overt (and covert) intentions of the document. >> >> To fix errors in RFC 4282. To codify existing practices. To suggest that use of standard formats is better than ad hoc formats. >> >> >>> "Omitting the username part is RECOMMENDED over using a fixed username >>> part, such as "anonymous", since it provides an unambiguous way to >>> determine whether the username is intended to uniquely identify a >>> single user." >>> >>> I don't understand why this is true, other than by convention. If I >>> process a bunch of authentication transactions that use "@example.com" as >>> the NAI, how am I supposed to know that each of those was intended to >>> identify a single user? Is the usage of an NAI to authenticate a group of >>> users discussed somewhere? >> The intent was to discuss EAP methods such as PEAP or TTLS. They provide for an opaque outer identity: “anonymous@realm”, or simply “@realm”. The only purpose of that identity is to allow intermediate nodes to *route* the traffic. >> >> The home node will terminate the EAP / TLS tunnel, and decode the inner data. That data will contain an NAI which will identify one user to be authenticated. >> >>> In general, I'm uncomfortable with the approach this document takes of >>> making a few notes about how the username part could be constructed >>> without providing a more thorough analysis of threats and mitigations >>> related to identifiability, uniqueness and persistence. >> Allocation of usernames is something best managed by organizations, using practices specific to that organization. I see no feasible way that the IETF can mandate internal organizational behaviour. All we can do is recommend that the *publicly* visible portions of the identifier are anonymous. >> >> See my suggested text (response to Barry) for details. If the public face of the NAI is simple “@realm”, then there are *no* IETF activities related to username identifiability, uniqueness, and persistence. >> >>> or the consequences of it (although being able to omit >>> the username part is certainly a format issue). >> Only in that there’s a requirement that the username portion be omitted, and that requirement affects the format. >> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> = Section 1 = >>> Is dial-up really a prevalent use case to be highlighting first here? If >>> we're going to obsolete an old document, it's worth making it current. >> That text is largely left over from RFC 4282. People still use dial-up. >> >>> Similarly, I wonder how current this text is in Section 1.3? >>> >>> "As described in [RFC2194], there are a number of providers offering >>> network access services, and the number of Internet Service Providers >>> involved in roaming consortia is increasing rapidly.” >> Perhaps that could say: >> >> As described in [RFC2194], there are a number of providers offering >> network access services, and essentially all Internet Service Providers >> are involved in roaming consortia. > . > From nobody Thu Dec 4 09:07:09 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EBA1AD4B8; Thu, 4 Dec 2014 09:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6a0AZ9ElVBU; Thu, 4 Dec 2014 09:07:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2981A1B92; Thu, 4 Dec 2014 09:07:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141204170700.14717.94231.idtracker@ietfa.amsl.com> Date: Thu, 04 Dec 2014 09:07:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/P4kiTpo_nSvyIYP-Hdt598yj4YU Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-nai-13.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 17:07:07 -0000 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 : The Network Access Identifier Author : Alan DeKok Filename : draft-ietf-radext-nai-13.txt Pages : 29 Date : 2014-12-04 Abstract: In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282, 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 4 09:59:07 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAC31A877F; Thu, 4 Dec 2014 09:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv_LxYXDMb7M; Thu, 4 Dec 2014 09:59:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 368861A1BDE; Thu, 4 Dec 2014 09:59:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141204175905.7549.58191.idtracker@ietfa.amsl.com> Date: Thu, 04 Dec 2014 09:59:05 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/M2aO1C-xt2hjJIr8TFAcBASfKOg Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-nai-14.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 17:59:06 -0000 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 : The Network Access Identifier Author : Alan DeKok Filename : draft-ietf-radext-nai-14.txt Pages : 29 Date : 2014-12-04 Abstract: In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282, 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 5 04:30:05 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB891ACE52; Fri, 5 Dec 2014 04:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyImKlEiDWIT; Fri, 5 Dec 2014 04:30:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 194D11ACE57; Fri, 5 Dec 2014 04:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jouni Korhonen" To: bclaise@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205123002.4553.10243.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 04:30:02 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/budsuDPi-CgEfAvEHaIv6hew3Bg Cc: radext@ietf.org, iesg-secretary@ietf.org, draft-ietf-radext-dynamic-discovery.all@tools.ietf.org, radext-chairs@tools.ietf.org, jounikor@gmail.com Subject: [radext] Publication has been requested for draft-ietf-radext-dynamic-discovery-12 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 12:30:04 -0000 Jouni Korhonen has requested publication of draft-ietf-radext-dynamic-discovery-12 as Experimental on behalf of the RADEXT working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ From nobody Fri Dec 5 05:01:34 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A031D1ACE72 for ; Fri, 5 Dec 2014 05:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HtDJXa6XRxx; Fri, 5 Dec 2014 05:01:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D6F1A0248; Fri, 5 Dec 2014 05:01:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: radext@ietf.org, draft-ietf-radext-dynamic-discovery.all@tools.ietf.org, radext-chairs@tools.ietf.org, jounikor@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205130131.8242.76610.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 05:01:31 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/radext/M2SnAtJl6hAoIPT6HO9KVZ4bvr0 Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 13:01:32 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ From nobody Tue Dec 9 03:48:23 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BD31A0101 for ; Tue, 9 Dec 2014 03:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AehZQB_ON9K for ; Tue, 9 Dec 2014 03:48:21 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBEC1A1A93 for ; Tue, 9 Dec 2014 03:48:16 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so370426lbj.13 for ; Tue, 09 Dec 2014 03:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NDw4mHh9cuHEeQLHo67/iF08u9jdvl1wcitqvJigmuk=; b=A7PffP8Bn2fXKcFE4yyG/sSrB2MM4hkPIxPbn8pO22AzlDLZ+OduPq+ARTWpzbaskj bXPEefQ4m230Dk5UE1bO68sdkCuUO17XWVipbSAbFlzAfUDR59wqaCoxI0+9qskUJh7I smI9n9sPuMZ7vsEElN9MNHfrSz11M+X8qA70Fe+/AcwyGf7gYChM+SaJAPQGIlKXcOdr FE5Nn4AEwM3Ev0o3twVdxo8LTaX8KpIKy4pHq/0ftz/EJm5OELhuemCn5nW76ahCPMNu hBzBLyDPuf/5Z7+EcUBLQv2Qr1etBMIKObf5toJdXmPC7ozvX0HT4SQ1QAsr2XMzltd9 qqow== X-Received: by 10.152.27.202 with SMTP id v10mr21239136lag.13.1418125695032; Tue, 09 Dec 2014 03:48:15 -0800 (PST) Received: from [10.17.0.23] ([83.150.126.201]) by mx.google.com with ESMTPSA id xs6sm302000lbb.13.2014.12.09.03.48.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Dec 2014 03:48:13 -0800 (PST) Message-ID: <5486E16F.6060102@gmail.com> Date: Tue, 09 Dec 2014 13:47:59 +0200 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <54476510.10903@gmail.com> In-Reply-To: <54476510.10903@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/yqw8Kg57LBwePnYhF0_AWVRiqFk Cc: Sam Hartman , Stefan Winter Subject: Re: [radext] WGLC for draft-ietf-radext-bigger-packets-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 11:48:22 -0000 Folks, The WGLC #1 ended a while ago.. we did receive one set of review comments from Alan. Those should be reflected in a new revision of the I-D. Since the WGLC #1 resulted to only this one review, we are going to call another WGLC after -02 revision is out. - Jouni & Stefan 10/22/2014 11:04 AM, Jouni Korhonen kirjoitti: > Folks, > > This email starts a two week WGLC for the I-D: > draft-ietf-radext-bigger-packets-01 > > Voice your support, comments and concerns on the list. The WGLC ends 5th > November EOB (EEST). In the case of issues or other enhancement > proposals, please enter them also into the issue tracker. > > - Jouni & Stefan From nobody Wed Dec 10 02:17:33 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BB71A6F04 for ; Wed, 10 Dec 2014 02:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbR009hB96Il for ; Wed, 10 Dec 2014 02:17:28 -0800 (PST) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id EF3751A1A2E for ; Wed, 10 Dec 2014 02:17:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id BBC1848220 for ; Wed, 10 Dec 2014 11:17:22 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3FgeHHqp1ULp for ; Wed, 10 Dec 2014 11:17:22 +0100 (CET) Received: from [155.54.205.116] (inf-205-116.inf.um.es [155.54.205.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon21.um.es (Postfix) with ESMTPSA id A886C4821F for ; Wed, 10 Dec 2014 11:17:21 +0100 (CET) Message-ID: <54881DB1.3000206@um.es> Date: Wed, 10 Dec 2014 11:17:21 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: radext@ietf.org References: <54476510.10903@gmail.com> <5486E16F.6060102@gmail.com> In-Reply-To: <5486E16F.6060102@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/so2YNts_Sqsv93KJHx11Gb4Xisg Subject: Re: [radext] WGLC for draft-ietf-radext-bigger-packets-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 10:17:30 -0000 Hi, I will review -02 revision. Regards, Alejandro El 09/12/14 a las 12:47, Jouni Korhonen escribió: > Folks, > > The WGLC #1 ended a while ago.. we did receive one set of review > comments from Alan. Those should be reflected in a new revision of the > I-D. > > Since the WGLC #1 resulted to only this one review, we are going to > call another WGLC after -02 revision is out. > > - Jouni & Stefan > > 10/22/2014 11:04 AM, Jouni Korhonen kirjoitti: >> Folks, >> >> This email starts a two week WGLC for the I-D: >> draft-ietf-radext-bigger-packets-01 >> >> Voice your support, comments and concerns on the list. The WGLC ends 5th >> November EOB (EEST). In the case of issues or other enhancement >> proposals, please enter them also into the issue tracker. >> >> - Jouni & Stefan > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Wed Dec 10 05:01:17 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC5B1A8A3D for ; Wed, 10 Dec 2014 05:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrvYHjeAHVx7 for ; Wed, 10 Dec 2014 05:01:10 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC431A8943 for ; Wed, 10 Dec 2014 05:01:10 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gd6so2368198lab.29 for ; Wed, 10 Dec 2014 05:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=SDgoV/BXq92NIxPgvcQRoaCeDWnl+3bzB6Ecw2S6Khs=; b=mQpO242tYFgyGIwtMI2cusVW1lKIBD8FylCt4+96Bypry9EYaKsUZYFvwILaYM2RhF EXKJ4f/w6ehU2mNFFcZaeMKkt3MHwiL0Xto1FD8vwoaG9Dd/Rxfmm5DdJ/aXVHXumdzV wYNCp/4I35cm2Pj8hdK89BonAippG1Cp9ESJvhOd2sYsPeA22BfcMMPGPpnC4J8t5exk KuBFsCE/E+cUy2CKDBoTaByIK6P4+spss5+xqlHfmkKUA8pPg7PSwQMuGlCqXTGw53dz IkMQizM5cAnkiJ2vfMecx/SqjMV96lXATuwcCg6YtoYgpYIggsF51XyDR2K0FENUdZYI BZlw== X-Received: by 10.152.2.74 with SMTP id 10mr3985946las.38.1418216468780; Wed, 10 Dec 2014 05:01:08 -0800 (PST) Received: from [10.17.0.23] ([83.150.126.201]) by mx.google.com with ESMTPSA id wn9sm1226034lbb.6.2014.12.10.05.01.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 05:01:07 -0800 (PST) Message-ID: <54884412.2000803@gmail.com> Date: Wed, 10 Dec 2014 15:01:06 +0200 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alejandro Perez Mendez , radext@ietf.org References: <54476510.10903@gmail.com> <5486E16F.6060102@gmail.com> <54881DB1.3000206@um.es> In-Reply-To: <54881DB1.3000206@um.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/W0n9dEHTuqAjfYhFFkxvypJkP8g Subject: Re: [radext] WGLC for draft-ietf-radext-bigger-packets-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 13:01:16 -0000 Thanks Alejandro. - JOuni 12/10/2014 12:17 PM, Alejandro Perez Mendez kirjoitti: > Hi, > > I will review -02 revision. > > Regards, > Alejandro > > El 09/12/14 a las 12:47, Jouni Korhonen escribió: >> Folks, >> >> The WGLC #1 ended a while ago.. we did receive one set of review >> comments from Alan. Those should be reflected in a new revision of the >> I-D. >> >> Since the WGLC #1 resulted to only this one review, we are going to >> call another WGLC after -02 revision is out. >> >> - Jouni & Stefan >> >> 10/22/2014 11:04 AM, Jouni Korhonen kirjoitti: >>> Folks, >>> >>> This email starts a two week WGLC for the I-D: >>> draft-ietf-radext-bigger-packets-01 >>> >>> Voice your support, comments and concerns on the list. The WGLC ends 5th >>> November EOB (EEST). In the case of issues or other enhancement >>> proposals, please enter them also into the issue tracker. >>> >>> - Jouni & Stefan >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Wed Dec 10 23:56:37 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1755B1ACCFD; Wed, 10 Dec 2014 23:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vIMG9MY9UDv; Wed, 10 Dec 2014 23:56:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 865671A01E7; Wed, 10 Dec 2014 23:56:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141211075633.4954.94432.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 23:56:33 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/6ZCAU_XcWaPQCzie1wR6Pv-tkj0 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-09.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 07:56:35 -0000 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 : Support of fragmentation of RADIUS packets Authors : Alejandro Perez-Mendez Rafa Marin-Lopez Fernando Pereniguez-Garcia Gabriel Lopez-Millan Diego R. Lopez Alan DeKok Filename : draft-ietf-radext-radius-fragmentation-09.txt Pages : 35 Date : 2014-12-10 Abstract: The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and are designed to be invisible to proxies, and "fail-safe" to legacy RADIUS Clients and Servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 11 00:05:18 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9D81ACCFD for ; Thu, 11 Dec 2014 00:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xoWVliPmTrC for ; Thu, 11 Dec 2014 00:04:50 -0800 (PST) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id C56871A8A0F for ; Thu, 11 Dec 2014 00:04:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 4BB06C283; Thu, 11 Dec 2014 09:04:47 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ULvlfTQxe8sV; Thu, 11 Dec 2014 09:04:47 +0100 (CET) Received: from [10.42.0.18] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon22.um.es (Postfix) with ESMTPSA id A4A7CA61; Thu, 11 Dec 2014 09:04:45 +0100 (CET) Message-ID: <5489501C.9070604@um.es> Date: Thu, 11 Dec 2014 09:04:44 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <20141211075633.4954.94432.idtracker@ietfa.amsl.com> In-Reply-To: <20141211075633.4954.94432.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060900010609040900090706" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/xq3_b8KmkVD5sFrxebu208yfuVE Cc: Benoit Claise , barryleiba@computer.org Subject: Re: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-09.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 08:05:08 -0000 This is a multi-part message in MIME format. --------------060900010609040900090706 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, we have submitted a new revision of our draft, addressing Benoit's and Barry's comments raised during AD's review. Most notably, we have introduced a new section called "Document status", where the details of the experiment are detailed. We've also added RFCs 2865, 6158 in the "updates" clause. Best regards, Alejandro > 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 : Support of fragmentation of RADIUS packets > Authors : Alejandro Perez-Mendez > Rafa Marin-Lopez > Fernando Pereniguez-Garcia > Gabriel Lopez-Millan > Diego R. Lopez > Alan DeKok > Filename : draft-ietf-radext-radius-fragmentation-09.txt > Pages : 35 > Date : 2014-12-10 > > Abstract: > The Remote Authentication Dial-In User Service (RADIUS) protocol is > limited to a total packet size of 4096 octets. Provisions exist for > fragmenting large amounts of authentication data across multiple > packets, via Access-Challenge. No similar provisions exist for > fragmenting large amounts of authorization data. This document > specifies how existing RADIUS mechanisms can be leveraged to provide > that functionality. These mechanisms are largely compatible with > existing implementations, and are designed to be invisible to > proxies, and "fail-safe" to legacy RADIUS Clients and Servers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------060900010609040900090706 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Dear all,

we have submitted a new revision of our draft, addressing Benoit's and Barry's comments raised during AD's review. Most notably, we have introduced a new section called "Document status", where the details of the experiment are detailed. We've also added RFCs 2865, 6158 in the "updates" clause.

Best regards,
Alejandro 

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           : Support of fragmentation of RADIUS packets
        Authors         : Alejandro Perez-Mendez
                          Rafa Marin-Lopez
                          Fernando Pereniguez-Garcia
                          Gabriel Lopez-Millan
                          Diego R. Lopez
                          Alan DeKok
	Filename        : draft-ietf-radext-radius-fragmentation-09.txt
	Pages           : 35
	Date            : 2014-12-10

Abstract:
   The Remote Authentication Dial-In User Service (RADIUS) protocol is
   limited to a total packet size of 4096 octets.  Provisions exist for
   fragmenting large amounts of authentication data across multiple
   packets, via Access-Challenge.  No similar provisions exist for
   fragmenting large amounts of authorization data.  This document
   specifies how existing RADIUS mechanisms can be leveraged to provide
   that functionality.  These mechanisms are largely compatible with
   existing implementations, and are designed to be invisible to
   proxies, and "fail-safe" to legacy RADIUS Clients and Servers.


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

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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

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

--------------060900010609040900090706-- From nobody Thu Dec 11 01:50:21 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67771ACD9A for ; Thu, 11 Dec 2014 01:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry7X6k7o74ph for ; Thu, 11 Dec 2014 01:50:18 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7E31A1BF4 for ; Thu, 11 Dec 2014 01:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7030; q=dns/txt; s=iport; t=1418291419; x=1419501019; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=rfgd/Ebht6QNcUIcxSr8qk6hnSsCyvI8/CfSMa2VkX4=; b=ccE13guUwxkPQO/pAjp0G+YNLd6V+zpNVYkhFqv/Bbm3h9nuuLi9xgcQ a4hd6WqBq/mh02UECDRHzIl2EK78jOGtP2yFWjdV85CQko1G65e9ObT/T gjVDJTYnaaxQfgH/2sgbCGtTs4rntrVjpMvyPDLVVApjBMbNGqNvZKUSG o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoEAKxniVStJssW/2dsb2JhbABZg1hTBcVmAQuFIkoCgTEBAQEBAX2EDQEBBAEBAWsKARALIRYPCQMCAQIBFTAGAQwBBQIBAQWIIwgF1ywBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjw5YBwmEIAWRPYUvgQwwgi2CEIs6IoNtPTCBA4FAAQEB X-IronPort-AV: E=Sophos;i="5.07,556,1413244800"; d="scan'208,217";a="269405511" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 11 Dec 2014 09:50:17 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBB9oFXv018859; Thu, 11 Dec 2014 09:50:15 GMT Message-ID: <548968D7.6010108@cisco.com> Date: Thu, 11 Dec 2014 10:50:15 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Alejandro Perez Mendez , "radext@ietf.org" References: <20141211075633.4954.94432.idtracker@ietfa.amsl.com> <5489501C.9070604@um.es> In-Reply-To: <5489501C.9070604@um.es> Content-Type: multipart/alternative; boundary="------------060705020301060509020200" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/OMGuubtXSKpmGAYOEWKPyMMvVpM Cc: barryleiba@computer.org Subject: Re: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-09.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 09:50:19 -0000 This is a multi-part message in MIME format. --------------060705020301060509020200 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Thank you Alejandro, I reviewed the new versions: the changes look good. I'm sending the draft to IETF LC. Regards, Benoit > Dear all, > > we have submitted a new revision of our draft, addressing Benoit's and > Barry's comments raised during AD's review. Most notably, we have > introduced a new section called "Document status", where the details > of the experiment are detailed. We've also added RFCs 2865, 6158 in > the "updates" clause. > > Best regards, > Alejandro > >> 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 : Support of fragmentation of RADIUS packets >> Authors : Alejandro Perez-Mendez >> Rafa Marin-Lopez >> Fernando Pereniguez-Garcia >> Gabriel Lopez-Millan >> Diego R. Lopez >> Alan DeKok >> Filename : draft-ietf-radext-radius-fragmentation-09.txt >> Pages : 35 >> Date : 2014-12-10 >> >> Abstract: >> The Remote Authentication Dial-In User Service (RADIUS) protocol is >> limited to a total packet size of 4096 octets. Provisions exist for >> fragmenting large amounts of authentication data across multiple >> packets, via Access-Challenge. No similar provisions exist for >> fragmenting large amounts of authorization data. This document >> specifies how existing RADIUS mechanisms can be leveraged to provide >> that functionality. These mechanisms are largely compatible with >> existing implementations, and are designed to be invisible to >> proxies, and "fail-safe" to legacy RADIUS Clients and Servers. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-09 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-09 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > --------------060705020301060509020200 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Thank you Alejandro,

I reviewed the new versions: the changes look good.
I'm sending the draft to IETF LC.

Regards, Benoit
Dear all,

we have submitted a new revision of our draft, addressing Benoit's and Barry's comments raised during AD's review. Most notably, we have introduced a new section called "Document status", where the details of the experiment are detailed. We've also added RFCs 2865, 6158 in the "updates" clause.

Best regards,
Alejandro 

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           : Support of fragmentation of RADIUS packets
        Authors         : Alejandro Perez-Mendez
                          Rafa Marin-Lopez
                          Fernando Pereniguez-Garcia
                          Gabriel Lopez-Millan
                          Diego R. Lopez
                          Alan DeKok
	Filename        : draft-ietf-radext-radius-fragmentation-09.txt
	Pages           : 35
	Date            : 2014-12-10

Abstract:
   The Remote Authentication Dial-In User Service (RADIUS) protocol is
   limited to a total packet size of 4096 octets.  Provisions exist for
   fragmenting large amounts of authentication data across multiple
   packets, via Access-Challenge.  No similar provisions exist for
   fragmenting large amounts of authorization data.  This document
   specifies how existing RADIUS mechanisms can be leveraged to provide
   that functionality.  These mechanisms are largely compatible with
   existing implementations, and are designed to be invisible to
   proxies, and "fail-safe" to legacy RADIUS Clients and Servers.


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

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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

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


--------------060705020301060509020200-- From nobody Thu Dec 11 05:13:31 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759E41ACE2E for ; Thu, 11 Dec 2014 05:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S62OQJHimHz6 for ; Thu, 11 Dec 2014 05:13:22 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645A51A88B6 for ; Thu, 11 Dec 2014 05:13:22 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id 10so4173917lbg.33 for ; Thu, 11 Dec 2014 05:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=66fDylogj0wsAl6feVEr2d7p8BpmXcSVXtU6lFW9Ztk=; b=PpgQxCnZnO/nBlw1KSBd1JnU0Zbfxw+iOPEuh1+i4+YdTD+/e33VpSfyNtreyYydno tAcCnGhDI4d3QaKHlP6IxvPFniiTXcn+NLX6zvgedD2d4jj+7pL1PPwJ15Q9D6reUqwT ZR0V8mxeAay+W5jvOM2jI8VDiZm6hwP8wYVZXt4HsQf5iOZmrdpGEWDK7wncjjHdIJZf MOwpvIjALRgEWr8bmSpiM4z5Lp9OyFFLlum3O9vGumFQ1WCtxVXPAXLPCSqFC64Q6gfU yhZLsYj6DMz6HgGoAlx7T2JLGORBSfa0qfQbh3Eg7/VDsU/sA/xR8b09iIZiqT8ad+sL VyyA== MIME-Version: 1.0 X-Received: by 10.112.41.168 with SMTP id g8mr9644840lbl.59.1418303600761; Thu, 11 Dec 2014 05:13:20 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Thu, 11 Dec 2014 05:13:20 -0800 (PST) In-Reply-To: <548968D7.6010108@cisco.com> References: <20141211075633.4954.94432.idtracker@ietfa.amsl.com> <5489501C.9070604@um.es> <548968D7.6010108@cisco.com> Date: Thu, 11 Dec 2014 08:13:20 -0500 X-Google-Sender-Auth: oc89pw4LYW-pVx0fu9u2BezqMZU Message-ID: From: Barry Leiba To: Benoit Claise Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/4s12-CNMd9t7QZ6mIqaoD4FdFik Cc: "radext@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-09.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 13:13:29 -0000 > Thank you Alejandro, > > I reviewed the new versions: the changes look good. > I'm sending the draft to IETF LC. I agree, and thanks. Barry From nobody Thu Dec 11 06:45:16 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0373E1ACEFB; Thu, 11 Dec 2014 06:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3jfjIB58W6q; Thu, 11 Dec 2014 06:45:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B73E1A902F; Thu, 11 Dec 2014 06:45:13 -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: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141211144513.26300.33968.idtracker@ietfa.amsl.com> Date: Thu, 11 Dec 2014 06:45:13 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/GFCu_UYZtLspzqFcKCEcoh9bDlM Cc: radext@ietf.org Subject: [radext] Last Call: (Support of fragmentation of RADIUS packets) to Experimental RFC X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 11 Dec 2014 14:45:15 -0000 The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'Support of fragmentation of RADIUS packets' as Experimental RFC 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 2014-12-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 limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and are designed to be invisible to proxies, and "fail-safe" to legacy RADIUS Clients and Servers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Dec 12 05:40:13 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056231A1B38; Fri, 12 Dec 2014 05:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqxXCrsSIy6q; Fri, 12 Dec 2014 05:40:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEED1A8706; Fri, 12 Dec 2014 05:40:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212134010.25977.78500.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 05:40:10 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/VI1x3nNaxZ8-DU1rTkublg2ggV8 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ip-port-radius-ext-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 13:40:12 -0000 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 : RADIUS Extensions for IP Port Configuration and Reporting Authors : Dean Cheng Jouni Korhonen Mohamed Boucadair Senthil Sivakumar Filename : draft-ietf-radext-ip-port-radius-ext-02.txt Pages : 34 Date : 2014-12-12 Abstract: This document defines three new RADIUS attributes. For devices that implementing IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as CGN (Carrier Grade NAT), NAT64, Provider WLAN Gateway, etc. This document does not make any assumption about the deployment context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 17 07:03:00 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EC41A8A9A; Wed, 17 Dec 2014 07:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxkPzuIzeElh; Wed, 17 Dec 2014 07:02:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8531A88CF; Wed, 17 Dec 2014 07:02:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141217150255.32679.91864.idtracker@ietfa.amsl.com> Date: Wed, 17 Dec 2014 07:02:55 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/JzC4LgNGGH_U9B2p0N7l_bTklk8 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-nai-15.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 15:02:57 -0000 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 : The Network Access Identifier Author : Alan DeKok Filename : draft-ietf-radext-nai-15.txt Pages : 30 Date : 2014-12-17 Abstract: In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282, 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-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 17 07:03:04 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6DD1A8A9A for ; Wed, 17 Dec 2014 07:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clGRQbkG2xBz; Wed, 17 Dec 2014 07:02:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1C11A8914; Wed, 17 Dec 2014 07:02:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: radext@ietf.org, draft-ietf-radext-nai.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu, bclaise@cisco.com, jari.arkko@piuha.net X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141217150256.32679.64988.idtracker@ietfa.amsl.com> Date: Wed, 17 Dec 2014 07:02:56 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/wzwTzTWfUH4W74fuRngUW7xiBGs Subject: [radext] New Version Notification - draft-ietf-radext-nai-15.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 15:02:58 -0000 A new version (-15) has been submitted for draft-ietf-radext-nai: http://www.ietf.org/internet-drafts/draft-ietf-radext-nai-15.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-nai/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Dec 22 15:06:48 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FC81A1B80 for ; Mon, 22 Dec 2014 15:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9GzXWE-zsMO; Mon, 22 Dec 2014 15:06:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DE11A88D3; Mon, 22 Dec 2014 15:06:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141222230645.5370.5712.idtracker@ietfa.amsl.com> Date: Mon, 22 Dec 2014 15:06:45 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/radext/9aIt5nwUTvt9e1cywXUYSp69xpY Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 23:06:46 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Thu Dec 25 00:09:02 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FB61A8753; Thu, 25 Dec 2014 00:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8AEP3KtI5zZ; Thu, 25 Dec 2014 00:08:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9753C1A874E; Thu, 25 Dec 2014 00:08:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141225080850.8392.16837.idtracker@ietfa.amsl.com> Date: Thu, 25 Dec 2014 00:08:50 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/lwfsGWN8-juq2gjSQ11bOoP2pck Cc: iesg-secretary@ietf.org Subject: [radext] Last Call Expired: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 08:08:54 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup.