Subject: [radext] FW: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Nov 2011 14:28:33 +0100

FYI.

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, November 01, 2011 1:44 AM
To: [email-masked]
Cc: [email-masked]
Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Application Bridging for
Federated Access Beyond web Working Group of the IETF.

	Title           : A RADIUS Attribute, Binding and Profiles for
SAML
	Author(s)       : Josh Howlett
                          Sam Hartman
	Filename        : draft-ietf-abfab-aaa-saml-02.txt
	Pages           : 14
	Date            : 2011-10-31

   This document specifies a RADIUS attribute, binding and two profiles
   for the Security Assertion Mark-up Language (SAML).  The attribute
   provides RADIUS encapsulation of SAML protocol messages, while the
   binding describes the transport of this attribute, and the SAML
   protocol messages within, using RADIUS.  The profiles describe the
   application of this binding for Abfab authentication and assertion
   query/request.  The SAML RADIUS attribute and binding are defined
   generically to permit application in other scenarios, such as network
   access.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt
_______________________________________________
abfab mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/abfab

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 1 Nov 2011 15:28:49 -0700

This document includes a requirement for encoding of the NAI as per RFC 4282. 

Today, RADIUS implementations do not convert U-labels within the domain-portion of the NAI to A-labels, because the User-Name attribute is 8-bit clean and designed to handle UTF-8, as described within RFC 2865, Section 5.1.

As a result, RFC 4282 doesn't really apply to RADIUS, and mentioning that with respect to User-Name encoding is potentially confusing (and could create an interoperability problem that doesn't exist today). 

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

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 1 Nov 2011 15:28:49 -0700

---

From: Alan DeKok <[email-masked]>
Date: Wed, 02 Nov 2011 08:43:19 +0100

Bernard Aboba wrote:
> Today, RADIUS implementations do not convert U-labels within the
> domain-portion of the NAI to A-labels, because the User-Name attribute
> is 8-bit clean and designed to handle UTF-8, as described within RFC
> 2865, Section 5.1.

  I agree.  I pointed the document authors to my 4282bis, and they
pointed out it wasn't a published spec, or even a WG item.

> As a result, RFC 4282 doesn't really apply to RADIUS, and mentioning
> that with respect to User-Name encoding is potentially confusing (and
> could create an interoperability problem that doesn't exist today).

  This is the most important point for me.

  Is it time to move ahead with 4282bis?  There have been few comments
on the existing doc.  All it does is codify current practice.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 02 Nov 2011 08:43:19 +0100

Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Nov 2011 08:22:25 -0700

> on the existing doc.  All it does is codify current practice.
[BA] Given that the spec would create an incompatible variant of RADIUS,
I'd say that the situation is pretty serious, and that a document clarifying
the encoding of the NAI within RADIUS is critical. 

Beyond that though, it strikes me that we may also need a "RADIUS Change
Process" document.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Nov 2011 08:22:25 -0700

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Wed, 2 Nov 2011 23:32:38 +0000

We should discuss this at upcoming meeting.

Alan: I see that you posted a new rev of the NAI doc.  Are you amendable to presenting on your doc and framing in the context of the conversation below?

-MS

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Wednesday, November 02, 2011 8:22 AM
To: Alan DeKok
Cc: [email-masked]; [email-masked]
Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML)

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Wed, 2 Nov 2011 23:32:38 +0000

-MS

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Nov 2011 08:02:31 +0100

Sanchez, Mauricio (HP Networking) wrote:
> Alan: I see that you posted a new rev of the NAI doc.  Are you amendable
> to presenting on your doc and framing in the context of the conversation
> below? 

  Yes.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Nov 2011 08:02:31 +0100

Yes.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Nov 2011 10:43:41 +0100

> the encoding of the NAI within RADIUS is critical.

  OK.  Can we get support for this position on the various mailing lists?

  I suspect the abfab people want to work within the existing RADIUS
framework.  The main difficulty is that the only NAI specification is
4282.  If abfab has a normative dependency on an NAI spec, then
publishing 4282bis quickly is a good idea.

  The draft describes existing practices, and has no new recommendations
in it.  So it *should* be non-controversial.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Nov 2011 10:43:41 +0100

Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Nov 2011 14:39:45 +0100

Sam Hartman wrote:
> 4282 is currently a normative dependency of draft-ietf-abfab-gss-eap.

  That's a problem.  As Bernard said, 4282 mandates behavior which *no
one* implements.  Anyone implementing 4282 will be incompatible with all
known RADIUS systems.

  I think the goal of abfab is to be interoperable with existing RADIUS
roaming systems.

> I'd definitely want to understand the internationalization story before
> supporting  a new NAI spec.

  Short story: AAA systems shouldn't mangle the NAI.

  4282 demands NAI mangling, which is bad.

> I suspect others will feel similarly.  So, even if we all end up
> agreeing with you in the end, I'd expect it to be a careful
> process--definitely far beyond what I hope it takes to get
> draft-ietf-abfab-gss-eap approved.

  Then we have a problem.  The draft conflicts with real-world practice.

> Now, at least for ABFAB implementations, I don't think it's a big
> deal. I think we can leave all the processing up to the final AAA
> server.

  That's pretty much what is said by 4282bis.

> I think i18n is a topic we really need to discuss for ABFAB in IETF 82.

  And interoperability with RADIUS.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Nov 2011 14:39:45 +0100

Alan DeKok.

---

From: Josh Howlett <[email-masked]>
Date: Fri, 4 Nov 2011 10:02:46 +0000

>publishing 4282bis quickly is a good idea.

I think the alternative would be to define something abfab-specific, which
would be non-optimal for the reasons given. I would prefer to use 4282bis.

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Sam Hartman <[email-masked]>
Date: Fri, 04 Nov 2011 08:57:57 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> Bernard Aboba wrote:
    >> [BA] Given that the spec would create an incompatible variant of
    >> RADIUS, I'd say that the situation is pretty serious, and that a
    >> document clarifying the encoding of the NAI within RADIUS is
    >> critical.

    Alan>   OK.  Can we get support for this position on the various
    Alan> mailing lists?

    Alan>   I suspect the abfab people want to work within the existing
    Alan> RADIUS framework.  The main difficulty is that the only NAI
    Alan> specification is 4282.  If abfab has a normative dependency on
    Alan> an NAI spec, then publishing 4282bis quickly is a good idea.

    Alan>   The draft describes existing practices, and has no new
    Alan> recommendations in it.  So it *should* be non-controversial.

Uh. Good luck with that.
I'd definitely want to understand the internationalization story before
supporting  a new NAI spec.
I understand your concerns with 4282.

---

From: Josh Howlett <[email-masked]>
Date: Fri, 4 Nov 2011 10:02:46 +0000

Josh.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 04 Nov 2011 08:57:57 -0400

Uh. Good luck with that.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 7 Nov 2011 09:53:15 -0800

As an author of RFC 4282, I'd like to apologize for the mess that deeply flawed document has created.

If there is any way to avoid referencing it, that would be good.

> Date: Mon, 7 Nov 2011 16:38:27 +0100
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: ABFAB does not specify any changes to RADIUS
> 
> Sam Hartman wrote:
> > Alan, I just read Klaas's forward of the radext list in which you claim
> > that abfab documents specify an alternate use of the RADIUS username
> > attribute.  I now understand why you're so concerned about the NAI issue
> > and ABFAB.
> 
>   Thanks.
> 
> > However, I believe that what is really going on here is that we
> > introduced a bug in the most recent version of draft-ietf-abfab-aaa-saml
> > that was quickly pointed out on the list
> > and that will be quickly corrected.
> 
>   OK.  My only concern is avoiding dependency on RFC 4282, for reasons
> I'll outline below.
> 
> >  section 4.2 of draft-ietf-abfab-aaa-saml does in fact describe the use
> > of a NAI in the RADIUS user-name attribute.  I think we've already
> > agreed that section should not repeat parts of the RADIUS or RADIUS over
> > EAP binding.
> 
>   Yes.  My reading of that section is that the NAI format MUST follow
> RFC 4282.  I object to that, as 4282 requires punycoding of i18n NAIs,
> which *no one* does.
> 
> > We asked Josh to be a lot more detailed in draft-ietf-abfab-aaa-saml. He
> > was. Now we need to scale back in order to avoid incorrectly stating
> > what other specs like RADIUS and RADIUS over EAP already say.  This is
> > just a bug in a draft introduced very recently, not any plan to create
> > an alternate RADIUS.
> 
>   OK.  My $0.02 is that the reference to 4282 should be removed from
> draft-ietf-abfab-aaa-saml.  Even on other grounds, section 4.2 item (1)
> of that document is wrong.  It starts off with "The RADIUS client",
> followed by a description of NAIs, and routing packets.  RADIUS clients
> don't route packets.
> 
>   Instead, (and this is more directed at Josh), that text could be cut
> to the first sentence and a half:
> 
>    1.  The RADIUS client, acting as a SAML requester, transmits a SAML
>        request element within a RADIUS Access-Request message.  This
>        message MUST include a single instance of the RADIUS User-Name
>        attribute.
> 
>   Routing RADIUS packets based on NAI is *completely* outside of the
> scope of RADIUS clients, and largely outside of the scope of the SAML
> document.
> 
> > There is a document that discusses NAIs but is more stable:
> > 
> > Section 3.1 of wdoes talk about a name
> > format. It describes how the components of this name format map to
> > NAIs--in effect it describes how one could convert a NAI into a GSS-EAP
> > mechanism name.
> 
>   OK.
> 
> > However, draft-ietf-abfab-gss-eap never says that a NAI is sent in the
> > RADIUS username attribute.  In fact it doesn't refer to the RADIUS
> > username attribute at all, because the existing RADIUS specifications
> > already discuss that attribute.
> 
>   The problem is that RFC 4282 doesn't really refer to RADIUS, either.
> The only thing it says about RADIUS is: "NAIs are often transported in
> the User-Name attribute ..."
> 
>   RFC 4282 is an NAI specification.  So referring to it in
> draft-ietf-abfab-gss-eap means that implementors of the draft *must*
> follow the requirements of 4282.  These requirements are incompatible
> with *all known* EAP and RADIUS implementations.
> 
>   This isn't a RADIUS issue.  The issue is that 4282 is wrong.  The
> 4282bis draft explains this in detail.
> 
>   Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 7 Nov 2011 09:53:15 -0800

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Nov 2011 14:14:21 -0500

The only thing we need is a string with human semantics similar to a NAI
that has a realm portion after an at-sign and some portion (possibly
empty) before the at-sign.  I actually think 4282 is a fine reference
for the basic concept behind a NAI so long as we are not talking about
any of the encoding or string processing rules.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Nov 2011 14:14:21 -0500

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Mon, 07 Nov 2011 20:47:21 +0100

Sam Hartman wrote:
> empty) before the at-sign. 

  That's largely what the new NAI document proposes.

> I actually think 4282 is a fine reference

  They're tied together, unfortunately.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 07 Nov 2011 20:47:21 +0100

Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Nov 2011 14:58:59 -0500

Alan> Sam Hartman wrote:
    >> The only thing we need is a string with human semantics similar
    >> to a NAI that has a realm portion after an at-sign and some
    >> portion (possibly empty) before the at-sign.

    Alan>   That's largely what the new NAI document proposes.

    >> I actually think 4282 is a fine reference for the basic concept
    >> behind a NAI so long as we are not talking about any of the
    >> encoding or string processing rules.

    Alan>   They're tied together, unfortunately.

Give me a chance to try and specify what we mean without pulling in the
string encoding.  If I fail, we can just wrip out calling it a NAI
completely or note that it's intended to be compatible in concept with
the new NAI once published and use an informative reference.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Nov 2011 14:58:59 -0500

--Sam

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 7 Nov 2011 12:50:27 -0800

>     Alan>   They're tied together, unfortunately.

[BA] RFC 4282 tied them together.  But I agree with Sam that they are logically separate issues.   

> string encoding.  If I fail, we can just rip out calling it a NAI

[BA]  Give it a shot.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 7 Nov 2011 12:50:27 -0800

[BA]  Give it a shot.

---

From: jouni korhonen <[email-masked]>
Date: Tue, 15 Nov 2011 03:57:47 +0200

I got a naive question (just as a concerned WG participant) regarding the fate of RFC4282. NAIs are also used outside AAA protocols. One particular domain that comes to my mind is mobility and mobile networks. There are several systems that depend on RFC4282 (as a MUST) in non-AAA signaling and then later may or may not relay that as-is to AAA protocols. The good thing is that usually internationalization is not really on the table yet in these systems but not that far either. 

So, what would be the net effect if we start fiddling with RFC4282? Do we then also need to revisit bunch of other RFCs and especially look into non-IETF specifications..?

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Tue, 15 Nov 2011 03:57:47 +0200

- Jouni

---

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Nov 2011 09:55:43 +0100

> I got a naive question (just as a concerned WG participant) regarding the fate of RFC4282. NAIs are also used outside AAA protocols. One particular domain that comes to my mind is mobility and mobi…

  Do you have a reference to a non-AAA use of 4282?  From what I've
seen, the NAIs are used by those systems in the context of RADIUS and
EAP.  So they're really just RADIUS / EAP.

> So, what would be the net effect if we start fiddling with RFC4282? Do we then also need to revisit bunch of other RFCs and especially look into non-IETF specifications..?

  I don't think so.  The reason is that these specification depend on
user@realm format.  They do *not* depend on the ToAscii converted form
of the i18n realm.

  Some documents depend on the "decorated" format of the NAI as
discussed in Section 2.7 of 4282.  I'm not aware that this practice is
widespread.

  i.e. realm decorations *are* widespread.  Standardized formats are
*not* widespread.  There are a large variety of formats used in practice.

  My take is that a 4282bis will have minimal impact on existing
specifications and practices.  This is because the specifications and
practices do *not* depend on the practices of 4282 which have been
removed in 4282bis.

  A quick pass through documents yields:

4283 - NAI is user@realm

4284 - NAI is user@realm, allows for "decoration" for source routing

5113 - allows for decorated NAI

5421 - name / password is processed as per 4282.

5433 - identifiers are NAIs

5446 - references 4282

5677 - identifier is FQDN *or* NAI

5687 - references 4282

6155 - says that the NAI allows non-UTF8 realms.  Non-UTF-8 characters
     are escaped by \HEXHEX.  They define a mapping from this format to
     the 4282 format.  This appears to be a misunderstanding, as 4282
     requires that the "realm" portion be UTF-8.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Nov 2011 09:55:43 +0100

4283 - NAI is user@realm

5446 - references 4282

5687 - references 4282

---

From: jouni korhonen <[email-masked]>
Date: Wed, 16 Nov 2011 03:39:14 +0200

Alan,

Thanks for elaborating this further.. Some more stuff inline.

> user@realm format.  They do *not* depend on the ToAscii converted form

Right. But that is mostly a fortunate coincidence.

> *not* widespread.  There are a large variety of formats used in practice.

RFC5729 is referenced/mandated by 3GPP in the context of RFC4282 NAI decoration. Though, i do not know whether it is used in real deployments today..

>     requires that the "realm" portion be UTF-8.

Also RFC5149, RFC5729. Then bunch of e.g. 3GPP(2) specs but they basically use RFC4282 in EAP/RADIUS/Diameter context. 

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Wed, 16 Nov 2011 03:39:14 +0200

Alan,

- Jouni