Subject: Re: [abfab] [radext] RFC 4282 and RADIUS implementations (was abfab and SAML)

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

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.

  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: 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.

4282 is currently a normative dependency of draft-ietf-abfab-gss-eap.

    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.

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.

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.
I think i18n is a topic we really need to discuss for ABFAB in IETF 82.

---

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

> 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.

> supporting  a new NAI spec.

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

  4282 demands NAI mangling, which is bad.

> draft-ietf-abfab-gss-eap approved.

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

> deal. I think we can leave all the processing up to the final AAA

  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: Sam Hartman <[email-masked]>
Date: Mon, 07 Nov 2011 09:37:23 -0500

>> draft-ietf-abfab-gss-eap.

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

I think we can come up with text that makes it clear what's going on and
that leaves processing to the final AAA server.  I do support doing
that.  I do not support changing the dependency to a draft instead of an
RFC.

If we fail to be able to come up with clear text that makes our intent
clear, then I'll re-evaluate my position.

Obviously if the WG comes to some other consensus I'll be happy to
update the dependency.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 07 Nov 2011 17:06:34 +0100

Sam Hartman wrote:
> that leaves processing to the final AAA server.

  That isn't enough.  4282 requires that the NAI be mangled in order to
create a normal form.  This mangling is done *before* the NAI is used in
EAP.

  No NAI implementation does this.  Requiring compliance with 4282 means
that implementations of draft-ietf-abfab-gss-eap *cannot* inter-operate
with existing EAP implementations.

>  I do support doing

  I understand why.

  Alan DeKok.

---

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

Alan> Sam Hartman wrote:
    >> I think we can come up with text that makes it clear what's going
    >> on and that leaves processing to the final AAA server.

    Alan>   That isn't enough.  4282 requires that the NAI be mangled in
    Alan> order to create a normal form.  This mangling is done *before*
    Alan> the NAI is used in EAP.

    Alan>   No NAI implementation does this.  Requiring compliance with
    Alan> 4282 means that implementations of draft-ietf-abfab-gss-eap
    Alan> *cannot* inter-operate with existing EAP implementations.

Understood.
I believe we can also make it clear that the realm portion of a  GSS EAP
name is not mangled.