From nobody Thu Dec 4 09:32:50 2014 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B5E1A1B89 for ; Thu, 4 Dec 2014 09:32:48 -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 mTUHjs1TcP4y for ; Thu, 4 Dec 2014 09:32:45 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45DC91A0393 for ; Thu, 4 Dec 2014 09:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12541; q=dns/txt; s=iport; t=1417714364; x=1418923964; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=vZKOHgmHCurC6cAxZlOakUcYzn5BqgDiy5UAF2ZPszE=; b=EZN8kds4zn94MudiZEGwq7ruZhSGEwheSq1Y1iFf6TgFL9NFghLEa3Fn cmtFNJo4qqGFuxIBu29em6X9n1JwpONEKNVzLVYfmJmUAXHQINhawAIIa JAZOELBQd6/OHQ3/5XmN/tqtImBI5CEK+tXk0hMaWWLkW8MeF1KoeM2/E c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUEAHeZgFRIo8UY/2dsb2JhbABZg1hYxlSGFgKBNAEBAQEBfYQCAQEBAgEBawEKAgEFBwQcAwECAQkWDwkDAgECATsCCAYNAQUCAQGIMQkN1x0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXkFURBwaEPAWOGoYMhjSBI4V6JYhtg2mCNYFFPjABgkQBAQE X-IronPort-AV: E=Sophos; i="5.07,517,1413244800"; d="scan'208,217"; a="48152518" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 04 Dec 2014 17:32:25 +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 sB4HWJf0006958; Thu, 4 Dec 2014 17:32:22 GMT Message-ID: <54809A9D.5000106@cisco.com> Date: Thu, 04 Dec 2014 18:32: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: "aaa-doctors@ietf.org" References: <6D54372E-1B6E-4A11-84AC-6E8047D9400F@deployingradius.com> In-Reply-To: <6D54372E-1B6E-4A11-84AC-6E8047D9400F@deployingradius.com> X-Forwarded-Message-Id: <6D54372E-1B6E-4A11-84AC-6E8047D9400F@deployingradius.com> Content-Type: multipart/alternative; boundary="------------010803080101050600090202" Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/4FZYPoVLGo4MTqTjczAASy99OCw Cc: Russ Housley , Jari Arkko Subject: [AAA-DOCTORS] Fwd: Re: Jari Arkko's Discuss on draft-ietf-radext-nai-12: (with DISCUSS and COMMENT) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 17:32:48 -0000 This is a multi-part message in MIME format. --------------010803080101050600090202 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear all, During the IESG telechat today regarding draft-ietf-radext-nai (Btw, version 13 has been posted https://datatracker.ietf.org/doc/draft-ietf-radext-nai/ ), we received the following DISCUSS from Jari, and Russ Housely asked this question: Jari Arkko has raised a DISCUSS position that the "bang syntax" is NOT RECOMMENDED, but it appears that at least two 3GPP specifications make use of this syntax. Is liaison coordination needed? Basically, the conclusions from the call were that: 1. we should keep the bang syntax processing rules, which were part of RFC 4282 2. Jari is fine with the new proposed text by Alan, but this should really be the DIAMETER/3GGP people telling they're fine. How to check the point 2? Regards, Benoit -------- Original Message -------- Subject: Re: Jari Arkko's Discuss on draft-ietf-radext-nai-12: (with DISCUSS and COMMENT) Date: Thu, 4 Dec 2014 11:43:56 -0500 From: Alan DeKok To: Arkko Jari CC: The IESG , , On Dec 4, 2014, at 8:14 AM, Jari Arkko wrote: > I noticed the change from 4282 in terms of the bang syntax. This > isn't my favourite syntax, but conditions for its use were specified > in 4282. As far as I can see, the same conditions still exist in the > draft, but the draft adds that the usage is NOT RECOMMENDED, > and adds some rationale for this. Stating that the usage is > historical. For RADIUS at least. > I have two questions related to this. > > First, has the WG been aware of existing, not historical usage, > of this syntax? Quick search reveals that 3GPP networks use > a routing convention with the syntax, see > http://www.3gpp.org/DynaReport/23003.htm and > http://www.qtc.jp/3GPP/Specs/24302-a70.pdf (note that I'm not > the expert on these types of usage and there might be additional > examples, or the experts might understand the situation better > than what we can gain merely by looking at the existing specs). > In any case, I think the WG should be aware of existing realities > of deployed usage. We’re aware, but wary. > Secondly, does that usage change any of your recommendations? Yes. I’ll add some text to clarify this. The recommendation is more against *manual* management of routes (both routing and authentication credentials). I’ll add some text: ... In summary, network practices and capabilities have changed significantly since NAIs were first overloaded to define AAA routes through a network. While manually managed explicit path routing was once useful, the time has come for better methods to be used. Notwithstanding the above recommendations, we note that the above practice is widely used for Diameter routing [RFC5729]. The routes described there are managed automatically, from both credential provisioning and routing updates. Those routes also exist within a particular framework (typically 3G), where membership is controlled and system behavior is standardized. There are no known issues with using explicit routing in such an environment. > I'm trying to read the draft but I cannot find where it says explicitly > what > to do when an AAA system (such as a NAS or a proxy) performs such > normalisation. Are the results of the normalisation only used locally, > such > as for routing? Yes. Section 2.1: Strings which are not in Normal Form Composed (NFC) are not valid NAIs and SHOULD NOT be treated as such. Implementations which expect to receive a NAI, but which instead receive non-normalised (but otherwise valid) UTF-8 strings instead SHOULD attempt to create a local version of the NAI, which is normalized from the input identifier. This local version can then be used for local processing. I’ll add some text: This local version of the identifier MUST NOT be used outside of the local context. > I partially disagree with Stephen's suggestion to consider hiding realm > portions > in addition to user names. It is useful functionality, and to the extent > that it can > be supported by existing mechanisms (like omitting the sensitive part, or > using > the bang syntax in some manner) it should be noted. But this RFC-to-be is > > for describing very widely deployed functionality, and I wouldn't like to > see > additional requirements for intermediate RADIUS nodes as they quite > simply > are not implemented today, and hence it would be difficult to use them. I don’t think there are any additional requirements for intermediate RADIUS nodes. They simply receive an identifier, and forward it (or not). If username privacy is used, intermediate nodes will see “@example.com”, and not “user@example.com”, or “user@secure.example.com”, or “@secure.example.com” Alan DeKok. . --------------010803080101050600090202 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear all,

During the IESG telechat today regarding draft-ietf-radext-nai (Btw, version 13 has been posted https://datatracker.ietf.org/doc/draft-ietf-radext-nai/ ), we received the following DISCUSS from Jari, and Russ Housely asked this question:
  Jari Arkko has raised a DISCUSS position that the "bang syntax" is
  NOT RECOMMENDED, but it appears that at least two 3GPP specifications
  make use of this syntax.  Is liaison coordination needed?
Basically, the conclusions from the call were that:
1. we should keep the bang syntax processing rules, which were part of RFC 4282
2. Jari is fine with the new proposed text by Alan, but this should really be the DIAMETER/3GGP people telling they're fine.

How to check the point 2?

Regards, Benoit


-------- Original Message --------
Subject: Re: Jari Arkko's Discuss on draft-ietf-radext-nai-12: (with DISCUSS and COMMENT)
Date: Thu, 4 Dec 2014 11:43:56 -0500
From: Alan DeKok <aland@deployingradius.com>
To: Arkko Jari <jari.arkko@piuha.net>
CC: The IESG <iesg@ietf.org>, <radext-chairs@tools.ietf.org>, <draft-ietf-radext-nai@tools.ietf.org> 


On Dec 4, 2014, at 8:14 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
> I noticed the change from 4282 in terms of the bang syntax. This
> isn't my favourite syntax, but conditions for its use were specified
> in 4282. As far as I can see, the same conditions still exist in the
> draft, but the draft adds that the usage is NOT RECOMMENDED,
> and adds some rationale for this. Stating that the usage is
> historical.

  For RADIUS at least.

> I have two questions related to this.
> 
> First, has the WG been aware of existing, not historical usage, 
> of this syntax? Quick search reveals that 3GPP networks use
> a routing convention with the syntax, see
> http://www.3gpp.org/DynaReport/23003.htm and
> http://www.qtc.jp/3GPP/Specs/24302-a70.pdf (note that I'm not
> the expert on these types of usage and there might be additional
> examples, or the experts might understand the situation better
> than what we can gain merely by looking at the existing specs).
> In any case, I think the WG should be aware of existing realities
> of deployed usage.

  We’re aware, but wary.

> Secondly, does that usage change any of your recommendations?

  Yes.  I’ll add some text to clarify this.  The recommendation is more against *manual* management of routes (both routing and authentication credentials).  I’ll add some text:

...
In summary, network practices and capabilities have changed
significantly since NAIs were first overloaded to define AAA routes
through a network.  While manually managed explicit path routing was
once useful, the time has come for better methods to be used.

Notwithstanding the above recommendations, we note that the above practice
is widely used for Diameter routing [RFC5729].  The routes described
there are managed automatically, from both credential provisioning and
routing updates.  Those routes also exist within a particular
framework (typically 3G), where membership is controlled and system
behavior is standardized.  There are no known issues with using
explicit routing in such an environment.

> I'm trying to read the draft but I cannot find where it says explicitly
> what
> to do when an AAA system (such as a NAS or a proxy) performs such 
> normalisation. Are the results of the normalisation only used locally,
> such
> as for routing?

  Yes.  Section 2.1:

Strings which are not in Normal Form Composed (NFC)
are not valid NAIs and SHOULD NOT be treated as such.  Implementations
which expect to receive a NAI, but which instead receive
non-normalised (but otherwise valid) UTF-8 strings instead SHOULD
attempt to create a local version of the NAI, which is normalized from
the input identifier.  This local version can then be used for local
processing.

  I’ll add some text:

This local version of the identifier MUST NOT be used
outside of the local context.

> I partially disagree with Stephen's suggestion to consider hiding realm
> portions
> in addition to user names. It is useful functionality, and to the extent
> that it can
> be supported by existing mechanisms (like omitting the sensitive part, or
> using
> the bang syntax in some manner) it should be noted. But this RFC-to-be is
> 
> for describing very widely deployed functionality, and I wouldn't like to
> see
> additional requirements for intermediate RADIUS nodes as they quite
> simply
> are not implemented today, and hence it would be difficult to use them.

  I don’t think there are any additional requirements for intermediate RADIUS nodes.  They simply receive an identifier, and forward it (or not).

  If username privacy is used, intermediate nodes will see “@example.com”, and not “user@example.com”, or “user@secure.example.com”, or “@secure.example.com”

  Alan DeKok.

.


--------------010803080101050600090202-- From nobody Sat Dec 6 16:32:43 2014 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27931A3BA6 for ; Sat, 6 Dec 2014 16:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 uo_sRNEjwTOf for ; Sat, 6 Dec 2014 16:32:39 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 245A71A3BA5 for ; Sat, 6 Dec 2014 16:32:38 -0800 (PST) Received: by power.freeradius.org (Postfix, from userid 1000) id 93D3A2240650; Sun, 7 Dec 2014 01:32:07 +0100 (CET) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: <20141207003207.93D3A2240650@power.freeradius.org> Date: Sun, 7 Dec 2014 01:32:07 +0100 (CET) Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/3sFN_fVd6NrP286YG-7Dd_x0eLo Subject: [AAA-DOCTORS] Automatic tech report for Sun Dec 7 01:32:07 CET 2014 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 00:32:41 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-arch-13 In IESG processing - ID Tracker state draft-ietf-softwire-map-radius-02 Active From nobody Sat Dec 13 16:32:15 2014 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF17F1A020B for ; Sat, 13 Dec 2014 16:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 YMYO-G_6s-DA for ; Sat, 13 Dec 2014 16:32:13 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 053301A01E1 for ; Sat, 13 Dec 2014 16:32:12 -0800 (PST) Received: by power.freeradius.org (Postfix, from userid 1000) id 791E2224051E; Sun, 14 Dec 2014 01:32:10 +0100 (CET) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: <20141214003210.791E2224051E@power.freeradius.org> Date: Sun, 14 Dec 2014 01:32:10 +0100 (CET) Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/5Ayn-kCNTppG0RRmkYlbxjFaPZI Subject: [AAA-DOCTORS] Automatic tech report for Sun Dec 14 01:32:09 CET 2014 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 00:32:15 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-arch-13 In IESG processing - ID Tracker state draft-ietf-softwire-map-radius-02 Active From nobody Sat Dec 20 16:32:12 2014 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6191A00CF for ; Sat, 20 Dec 2014 16:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 HRidGDGRcNzv for ; Sat, 20 Dec 2014 16:32:09 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 91A2E1A00C3 for ; Sat, 20 Dec 2014 16:32:08 -0800 (PST) Received: by power.freeradius.org (Postfix, from userid 1000) id C4DA82240935; Sun, 21 Dec 2014 01:32:07 +0100 (CET) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: <20141221003207.C4DA82240935@power.freeradius.org> Date: Sun, 21 Dec 2014 01:32:07 +0100 (CET) Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/lzCRDux69Ex-Zu81-bZ1CX-7ZiY Subject: [AAA-DOCTORS] Automatic tech report for Sun Dec 21 01:32:07 CET 2014 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 00:32:12 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-arch-13 In IESG processing - ID Tracker state draft-ietf-softwire-map-radius-03 Active From nobody Sat Dec 27 16:32:42 2014 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8891ACE29 for ; Sat, 27 Dec 2014 16:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 0TSciW7UfFd7 for ; Sat, 27 Dec 2014 16:32:39 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8531ACE28 for ; Sat, 27 Dec 2014 16:32:38 -0800 (PST) Received: by power.freeradius.org (Postfix, from userid 1000) id 2B51E22406EB; Sun, 28 Dec 2014 01:32:07 +0100 (CET) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: <20141228003207.2B51E22406EB@power.freeradius.org> Date: Sun, 28 Dec 2014 01:32:07 +0100 (CET) Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/jWhyLEdprt8zmb4e0EGIW_RZrbs Subject: [AAA-DOCTORS] Automatic tech report for Sun Dec 28 01:32:06 CET 2014 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 00:32:41 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-arch-13 In IESG processing - ID Tracker state draft-ietf-softwire-map-radius-03 Active