Subject: [AAA-DOCTORS] Fwd: Re: Jari Arkko's Discuss on draft-ietf-radext-nai-12: (with DISCUSS and COMMENT)

From: Benoit Claise <[email-masked]>
Date: Thu, 04 Dec 2014 18:32:13 +0100

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 <[email-masked]>
To: 	Arkko Jari <[email-masked]>
CC: 	The IESG <[email-masked]>, <[email-masked]>, 
<[email-masked]>

On Dec 4, 2014, at 8:14 AM, Jari Arkko <[email-masked]> 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 “[email-masked]”, or “[email-masked]”, or “@secure.example.com”

   Alan DeKok.

.