Subject: [abfab] EAP applicability statement comment

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Jul 2012 14:48:18 +0100

Hi all,

During IESG processing of draft-ietf-abfab-gss-eap we agreed
to add a reference to the EAP applicability statement so that
when gss-eap becomes an RFC, its clear that we're ok. (The
gss-eap draft was approved btw, but we need to get that
escaping thing and a few nits sorted before you'll see the
announcement.)

I asked the IESG if adding that reference and having abfab
process the EAP applicability statement was ok and folks
were ok with that. I also got the comment below from Bernard
Aboba. That looks like it'd be useful to consider as you
process the EAP applicability statement which is on your
agenda for Vancouver.

It doesn't seem to me like this'd raise any nasty problems
for abfab, but then what do I know:-)

Cheers,
S.

"There is another issue here, which is the guidance in RFC 4962,
in particularly the requirement for a mandatory-to-implement
mechanism.

In enterprise WLAN network access, where enterprise users are
typically provided with access software by their employers -- there
is almost always a secure method satisfying the RFC 4017
requirements that is required for access to a given enterprise.
Similarly, carrier networks that have deployed EAP (e.g. WiMAX)
have also specified a mandatory-to-implement method (e.g., EAP-TLS).

However, in other deployment scenarios, such as consumer uses
where no AAA server is present and there are typically no EAP
methods supported on the device, there is no mechanism for
meeting the RFC 4962 requirements.   In those scenarios, EAP is
not a good fit.

The changes to the EAP applicability statement do not obsolve
authors advocating new uses of EAP from demonstrating adherence
to the RFC 4962 requirements."

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 Jul 2012 10:23:45 -0400

So, I'm really hoping that from a process standpoint we can not look to
hard at this.  I absolutely agree with Bernard that we need to implement
things that meet the 4962 requirements.

The implementation I have the most experience with (Moonshot) does
implement RFC 4962.  We use radsec as the key confidentiality method
between AAA server and client.

We basically require EAP-TTLS because that's all we're currently
implementing channel binding for.

The problem is that if we get too picky about IETF process, none of this
works.  In terms of standardized EAP methods with security, we have
EAP-GPSK and EAP-TLS.
EAP-TLS doesn't support channel binding and adding it would be
difficult.
EAP-GPSK probably is something we could use. However, it's the wrong fit
for a lot of deployments.

RADSEC is a good fit for what we want. Except it's not standards track.

Long term, TEAP will be a standards-track method we can move to.
Long term,  either diameter will catch on, or we'll decide that RADSEC
or some other form of security is appropriate for a normative reference
from a standards-track spec.

I don't think publishing ABFAB is experimental is the right approach.
I don't think blocking ABFAB until EAP and RADEXT get done coming up
with standards-track mechanisms is the right fix.

So, I'm left concluding that  being a bit liberal in our process and
doing something reasonable with the implementations is the right
approach here.

So, I think that the right fix for the applicability statement is simply
to refer to section 1.2 of RFC 4962 and note that is
mandatory-to-implement.

---

From: "Leif Johansson" <[email-masked]>
Date: Fri, 20 Jul 2012 17:38:41 +0200

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

---

From: "Leif Johansson" <[email-masked]>
Date: Fri, 20 Jul 2012 17:41:33 +0200

> to refer to section 1.2 of RFC 4962 and note that is

This approach sounds reasonable to me too.

---

From: Alper Yegin <[email-masked]>
Date: Wed, 25 Jul 2012 18:56:59 +0300

Another comment:

   In most network access use cases all access servers
   that are served by a particular EAP server are providing the same or
   very similar types of service.  The peer does not need to
   differentiate between different access network services supported by
   the same EAP server.

This is not accurate. In between the EAP peer and the EAP authentication server, there are zero or more independent service providers (access network provider, roaming exchange, roaming network provider). 
It's not like all of the access networks being served by the EAP auth server belong to the same service provider (that owns the EAP auth server too).
The type of service the mobile device gets differ too (e.g., roaming vs non-roaming).
Shouldn't the channel binding requirements equally apply to network access and non-network access cases?

Alper