Subject: Re: [abfab] EAP applicability statement comment

From: "Jim Schaad" <[email-masked]>
Date: Wed, 1 Aug 2012 18:18:34 -0700

While it is possible that one should require that network access services
should require that channel binding be required.  For the general purpose of
this update we are restricted to updating for ABFAB usage cases and thus do
not have the authority to put additional restrictions on the generic network
access service case.

That being said, the original presentations in the EMU group did refer to
the case of the lying NAS (either in terms of service ability or costs) as
one of the things that needed to be addressed.  This issue really needs to
be addressed in EMU (or maybe EAP) in order to become any type of
requirement.

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alper Yegin
Sent: Wednesday, July 25, 2012 8:57 AM
To: Leif Johansson
Cc: [email-masked]
Subject: Re: [abfab] EAP applicability statement comment

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

 

On Jul 20, 2012, at 6:41 PM, Leif Johansson wrote:

20 jul 2012 kl. 16:24 skrev "Sam Hartman" <[email-masked]>:

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.

_______________________________________________

abfab mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/abfab

This approach sounds reasonable to me too.

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