Subject: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Mar 2013 17:52:02 -0400

Dear Pete and Barry:

I think radext  could use some help on the i18n front; I'm fairly
convinced that a decision we seem to be making is the wrong approach,
but I don't have quite enough clue or mental bandwidth to argue it.
Briefly, we're debating where normalization of network access
identifiers should happen.
I'm reasonably sure that this is a case where normalization should
happen as close to use as possible.
The current thinking seems to be that normalization should happen on the
client and I think many of the reasons that have made that approach
problematic for other architectures apply here.

Any chance you could get someone to review this draft and take another
look at the issue?

Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt
From: Alan DeKok <[email-masked]>
To: Jim Schaad <[email-masked]>
Cc: 'Sam Hartman' <[email-masked]>, 'Stefan Winter' <[email-masked]>, [email-masked]
Date: Mon, 18 Mar 2013 15:34:04 -0400

  I agree with Jim here.

  As I write RADIUS servers instead of supplicants, I think the
normalization work should be pushed off onto supplicants.

  The document already says that realm names MUST be registrable as
names within DNS.  DNS requires NFC.  Therefore, realms are NFC.  Any
supplicant injecting non-NFC names is wrong.

  re: Sam's comments on i18n space, I'm not sure it's relevant to have
the home server normalize the realm name.  I'm curious to know what
information is in the non-NFC form which is needed by the home server.

  The home server knows who it's users are, and can just use names,
without a realm portion.  If it gets a realm, it verifies that it owns
the realm, but that verification is largely site-specific.  e.g.
EXAMPLE\foo versus [email-masked].

  So the main use for realms is proxies.  They don't care about the
*content* of the realm.  They just want to use it as an opaque token.
Realm A goes to RADIUS server for Realm A, etc.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Mar 2013 17:58:29 -0400

I agree that the NAI draft is broken, if only because "the client" can mean anything from a PPP peer to an HTTP client or SIP UA. Attempting to write a single ABNF covering HTTP and SIP URIs, as well as EAP, PPP, L2TP, IKEv2, etc. let alone to insist that RADIUS proxies have no role in normalization, seems to be contradicted by other RADEXT drafts as well as by experience and common sense.

On Mar 18, 2013, at 17:52, "Sam Hartman" <[email-masked]> wrote:

> <mime-attachment>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Mar 2013 18:16:36 -0400

Bernard Aboba wrote:
> I agree that the NAI draft is broken, if only because "the client" can mean anything from a PPP peer to an HTTP client or SIP UA.
 Attempting to write a single ABNF covering HTTP and SIP URIs, as well
as EAP, PPP, L2TP, IKEv2, etc. let alone to insist that RADIUS proxies
have no role in normalization, seems to be contradicted by other RADEXT
drafts as well as by experience and common sense.

  What other drafts require RADIUS proxies to normalize usernames / realms?

  What else can we do to replace RFC 4282, which is arguably *worse*
than the current draft?

  Alan DeKok.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 Mar 2013 15:17:46 -0700

Bernard,

Just so I can follow the argument.  Which RADEXT drafts are you referring
to?

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Bernard Aboba
> Sent: Monday, March 18, 2013 2:58 PM
> To: Sam Hartman
> Cc: [email-masked]; Pete Resnick; Barry Leiba
> Subject: Re: [radext] I18N help: : I-D Action:
draft-ietf-radext-nai-02.txt
> 
> I agree that the NAI draft is broken, if only because "the client" can
mean
> anything from a PPP peer to an HTTP client or SIP UA. Attempting to write
a
> single ABNF covering HTTP and SIP URIs, as well as EAP, PPP, L2TP, IKEv2,
> etc. let alone to insist that RADIUS proxies have no role in
normalization,
> seems to be contradicted by other RADEXT drafts as well as by experience
> and common sense.
> 
> > The current thinking seems to be that normalization should happen on
> > the client and I think many of the reasons that have made that
> > approach problematic for other architectures apply here.
> >

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Mar 2013 18:40:37 -0400

>  What other drafts require RADIUS proxies to normalize usernames / realms?

[BA] The Dynamic Discovery draft recognizes that realms won't necessarily appear in the User-Name attribute in normalized form. 

>  What else can we do to replace RFC 4282, which is arguably *worse*

[BA] Focus only on the scope that the Charter outlines for the document: the Network Access Identifier, which is a term that applies to Network Access alone. This includes EAP, PPP, etc. but NOT HTTP, SIP, etc.  The NAI draft should not talk about the contents of the RADIUS User-Name attribute -- that should be handled by a separate document.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Mar 2013 18:44:50 -0400

>>>>> "Pete" == Pete Resnick <[email-masked]> writes:

    Pete> Are these identifiers (usernames, realm names) things that
    Pete> users actually type in (i.e., user interface elements) or are
    Pete> they protocol elements? The answer will very much depend on
    Pete> which sort of thing they are. (And I have a sneaking suspicion
    Pete> that you're going to tell me that they are both, which is
    Pete> going to make your job much more difficult.) So, at what layer
    Pete> are these things used?

They're both.
Their use is very similar to Kerberos principals or jabber jids.
(Their format and the legacy issues are of course unique and special in
the worst possible way)

They can be typed in by users; for example on Android when you go
configure an EAP wireless network you type in a string that acts as a
NAI.
Or they can be provisioned.
For example, you can provision them centrally using Windows group
policy.
Provisioning is more recommended that typing in but both happen.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Mar 2013 19:02:16 -0400

>>>>> "Bernard" == Bernard Aboba <[email-masked]> writes:

    Bernard> [BA] Focus only on the scope that the Charter outlines for
    Bernard> the document: the Network Access Identifier, which is a
    Bernard> term that applies to Network Access alone. This includes
    Bernard> EAP, PPP, etc. but NOT HTTP, SIP, etc.  The NAI draft
    Bernard> should not talk about the contents of the RADIUS User-Name
    Bernard> attribute -- that should be handled by a separate document.

Bernard, unfortunately, some of us really need to cover
non-network-access use cases of EAP and we'd really like to see the same
treatment of network access use cases of EAP.
I'd prefer to keep all EAP use cases in this draft.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 Mar 2013 16:15:36 -0700

> Sent: Monday, March 18, 2013 3:41 PM
> To: Alan DeKok
> Cc: Sam Hartman; Pete Resnick; Barry Leiba; [email-masked]
> [BA] The Dynamic Discovery draft recognizes that realms won't necessarily
> appear in the User-Name attribute in normalized form.

The Dynamic Discovery draft recognizes the following:
1.  What is in the UserName field may not be an NAI
2.  What is in the UserName field realm portion needs to somehow be mapped
to a DNS name (much easier if already normalized).

Note that it does not talk about the process of normalization in any way.
It talks about how to map from a UTF-8 realm name to a DNS name.

Jim

> [BA] Focus only on the scope that the Charter outlines for the document:
the
> Network Access Identifier, which is a term that applies to Network Access
> alone. This includes EAP, PPP, etc. but NOT HTTP, SIP, etc.  The NAI draft
> should not talk about the contents of the RADIUS User-Name attribute --
> that should be handled by a separate document.
> 
> 
> >
> >  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Mar 2013 19:20:11 -0400

EAP use cases are fine.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Mar 2013 19:22:18 -0400

Point #1 is particularly relevant here - which is why handling the NAI and the RADIUS User-Name attribute in the same doc (as if they were the same) is do problematic.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 Mar 2013 17:24:50 -0700

So I just did  search in the document for User-Name just to see how
overlapped they are.  The document says 

* NAIs are often transported in the User-Name field of RADIUS and Diameter
* Putting localized text into a User-Name field is problematic (because
User-Name is not NAI)
* Don't do ToAscii on NAI before putting into a User-Name field.

Of that list only the last one seems to be an issue from the point of
separation.  The text seems to be very clear that they are not the same
thing.

Jim

> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Monday, March 18, 2013 4:22 PM
> To: Jim Schaad
> Cc: Alan DeKok; Sam Hartman; Pete Resnick; Barry Leiba; [email-masked]
> 
> Point #1 is particularly relevant here - which is why handling the NAI and
the
> RADIUS User-Name attribute in the same doc (as if they were the same) is
do
> problematic.
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Bernard Aboba
> >> [BA] The Dynamic Discovery draft recognizes that realms won't
> >> necessarily appear in the User-Name attribute in normalized form.
> >
> > 1.  What is in the UserName field may not be an NAI 2.  What is in the
> > UserName field realm portion needs to somehow be mapped to a DNS name
> > (much easier if already normalized).
> >
> >> Network Access Identifier, which is a term that applies to Network
> >> Access alone. This includes EAP, PPP, etc. but NOT HTTP, SIP, etc.
> >> The NAI draft should not talk about the contents of the RADIUS
> >> User-Name attribute -- that should be handled by a separate document.
> >>
> >>
> >>>
> >>> Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Mar 2013 11:11:10 -0400

> [BA] The Dynamic Discovery draft recognizes that realms won't necessarily appear in the User-Name attribute in normalized form. 

  Sure.  That's reality.  People do all kinds of horrible things with
protocols.

  But the text makes it clear it's about DNS:

   This document describes
   server discovery only for well-formed realms mapping to DNS domain
   names in UTF-8 encoding.

  And then:

   The result of all other possible contents
   of User-Name is unspecified;

  i.e. other forms are allowed, but "realm == DNS" is what the draft
describes.

> [BA] Focus only on the scope that the Charter outlines for the document: the Network Access Identifier, which is a term that applies to Network Access alone. This includes EAP, PPP, etc. but NOT HT…

  The document discusses how the NAI *may* be used in User-Name, and
other protocols.  It's meant as a guide for people who want to use the
NAI.  It's not a requirement on how other protocols (including RADIUS)
use the NAI.

  I'd oppose removing the text about protocols using NAI.  Doing that
means we're defining an NAI independent of... anything.  So we'll have
an NAI, but no idea of where or when to use it.

  Alan DeKok.

---

From: Pete Resnick <[email-masked]>
Date: Mon, 18 Mar 2013 16:31:25 -0600

This might be something we want to discuss in the contact of PRECIS, but 
let's get started just between us:

Are these identifiers (usernames, realm names) things that users 
actually type in (i.e., user interface elements) or are they protocol 
elements? The answer will very much depend on which sort of thing they 
are. (And I have a sneaking suspicion that you're going to tell me that 
they are both, which is going to make your job much more difficult.) So, 
at what layer are these things used?

pr

On 3/18/13 3:52 PM, Sam Hartman wrote:
> Subject:
> Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt
> From:
> CC:
> 'Sam Hartman' <[email-masked]>, 'Stefan Winter' 
> <[email-masked]>, <[email-masked]>
>
>
>    I agree with Jim here.
>

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Mar 2013 13:45:56 -0400

> let's get started just between us:

  I've been showing up at Precis for a while.

> at what layer are these things used?

  A large percentage of the identifiers will be entered by users.  They
will then be used in various protocols to identify the users, and the
domains to which the users belong.

  The traditional practice in RADIUS has been to allow pretty much
anything as identifiers.  The only requirement is that the user and home
system agree on the user identifier.

  The problem we're trying to solve here is proxies.  They connect
visited networks to home networks.  The proxies need a standard format
for the user identifier.  This is so that they can route domain A to
network A, etc.  The format of the user portion is less relevant to
proxies.  It can be pretty much anything.  (and is, in practice)

  Alan DeKok.