Subject: [eap] draft on authenticated service identities

From: Jari Arkko <[email-masked]>
Date: Fri, 02 Apr 2004 15:56:44 +0300

Pasi and I have written a draft on the authentication
of service identities (= service parameters claimed
by access servers) in EAP. Essentially, the draft
is an extension of EAP-TLS, EAP-SIM, EAP-AKA, and PEAPv2
for transporting and authenticating parameters related
to the offered service. This makes it possible to ensure,
for instance, that everyone agrees about the claimed SSID
or that a compromised access point can not present itself
as an IKEv2 gateway.

Here's the abstract:

    A common arrangement in network access is the separation of the
    actual network access device (such as a wireless LAN access point)
    from the authentication servers. In the Extensible Authentication
    Protocol (EAP) framework, different authentication methods can
    provide varying security properties. If the EAP methods support
    authentication of service identities, it becomes possible for the
    clients to verify not only that the access device is trusted, but
    also that the parameters advertised by the access device are correct.
    This document specifies a backward compatible extension to popular
    EAP methods for supporting such service identity authentication. A
    common parameter name space is created in order to ensure that the
    same parameters can be communicated independent of the choice of the
    authentication method.

The draft has been submitted, but before it appears
in the official directories, you can access it from
the following URLs:

   http://www.arkko.com/publications/eap/draft-arkko-eap-service-identity-auth-00.txt
   http://www.arkko.com/publications/eap/draft-arkko-eap-service-identity-auth-00.html

Comments are appreciated.

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 02 Apr 2004 07:14:40 -0800

Hi, Jari and Pasi

Here is my comments on your draft:

o It might be better to define Called-Station-Id and
Calling-Station-Id parameters as generic device identifiers instead of
defining service type dependent device identifiers.  More specifically:

   - SSID parameter and BSSID parameter for IEEE 802.11 can be
   replaced with Called-Station-Id parameter.  This is because RFC3580
   defines RADIUS Called-Station-Id attribute as the combination of
   MAC address of AP and SSID in the case of IEEE 802.11, and I
   believe the MAC address of AP is the BSSID.

   - STA_MAC parameter for IEEE 802.11 can be replaced with
   Calling-Station-Id parameter.  This is because RFC3580 defines
   RADIUS Calling-Station-Id attribute as the Supplicant MAC address.

   - PaC Device-Id and PAA Device-Id parameters for PANA can be
   replaced with Calling-Station-Id and Called-Station-Id parameters,
   respectively.

   - Initiator address and responder address parameters for IKEv2 can
   be replaced with Calling-Station-Id and Called-Station-Id
   parameters, respectively.

o How an EAP server can learn the service type parameter from NAS?
RADIUS NAS-Port-Type attribute may be used for this purpose but the
NAS-Port-Type is not suitable to represent media-independent EAP
transports such as PANA and IKEv2.

o How an EAP server can learn protection mechanism parameters from
NAS?  In other words, are there any RADIUS attributes or Diameter AVPs
currently defined to carry the protection mechanism parameters?

o It might be better to define a mechanism to indicate which service
parameter is incorrect when an error occurs, instead of just failing
the authentication.  The EAP-IKEv2 methods provides such a mechanism,
for example.

Regards,

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Fri, 02 Apr 2004 19:37:07 +0300

> Here is my comments on your draft:

Thanks for taking a look!

>    parameters, respectively.

Yes. I also thought about this a bit while working on the draft,
but did not do anything about it yet. I should say that the
initial set of parameters is very rough, I'm sure more discussion
is needed on it.

> transports such as PANA and IKEv2.

A general issue in the -00 draft is that it does not really define
the required mapping from the parameters to the AAA attributes.
I agree that there needs to be a way to determine which service
type was provided. In general, I suspect we can do this only partially
with current AAA attribute sets, and some ones may be needed.

> currently defined to carry the protection mechanism parameters?

See above. There aren't any such attributes to my knowledge.
These may have to be defined.

> the authentication.  The EAP-IKEv2 methods provides such a mechanism,

Sounds like a good suggestion, particularly in the view of incomplete
information that may be transferred over AAA.

--Jari

---

From: Florent Bersani <[email-masked]>
Date: Thu, 08 Apr 2004 14:44:57 +0200

Four very quick comments:

1) Many thanks for writing this draft! Indeed, while designing an EAP 
method or reviewing the existing ones, I formed the strong belief that 
much work could be saved (and better quality obtained) if EAP methods 
had a common pool from which they could pick up "standard" functions - 
such as channel binding - and focus on their specifics - such as the 
cryptographic parts. This belief echoes what Joe once proposed 
(EAP-TLV). I'll thus simply include a corresponding TLV and a reference 
to your draft on authenticated service identities in EAP-PSK to 
implement channel binding :-)

2) I agree that more discussion is needed regarding the parameters. For 
instance, I object with having WPA and 802.11i gathered to a single 
parameter value in section 3.3.4 page 8. it might prove important to 
differentiate between TKIP only and CCMP in the near future. In general 
more granularity could be provided for this section (not only WPA vs 
802.11i but perhaps also the unicast, group and AKM Ciphersuites). I'll 
try and provide a proposition for more detailed parameters - maybe input 
from IEEE 802.11i members could help?

3) Could and should the same work be done with error messages?

4) Your draft seems to collide with EAP media independence (at least 
from a wording point of view). Please see Bernard's mail below.

Cheers,

Florent

------- Original Message --------
Subject:     [eap] Issue 235: (Key Framework) Rewrite of Section 1
Date:     Sat, 3 Apr 2004 15:45:13 -0800 (PST)
From:     Bernard Aboba <[email-masked]>
To:     [email-masked]

1.4.1.  Media Independence

   One of the goals of EAP is to allow EAP methods to function on any
   lower layer meeting the criteria outlined in [RFC3748], Section 3.1.
   For example, as described in [RFC3748], EAP authentication can be run
   over PPP [RFC1661],  IEEE 802 wired networks [IEEE8021X], and IEEE
   802.11 wireless LANs [IEEE80211i].

   In order to maintain media independence, it is necessary for EAP to
   avoid inclusion of media-specific elements.  For example, EAP methods
   cannot be assumed to have knowledge of the lower layer over which
   they are transproted, and cannot utilize identifiers associated with
   a particular usage environment (e.g. MAC addresses).

---

From: Alper Yegin <[email-masked]>
Date: Mon, 12 Apr 2004 15:27:17 -0700

Hello Jari and Pasi,

Thanks for chasing this issue down and putting this draft together.

I agree something needs to be done regarding binding the service to the
authentication, and considering several service-related attributes is a
necessity.

The attribute verification can be performed in different ways. I see
your draft proposes it being done both on the peer and the
authentication server. This is somewhat redundant, unless I'm missing
something. Either peer or the auth. server could perform this
verification and fail the AAA in case of discrepancy (modulo the
policy). I guess giving the authority to perform this check and fail the
session to each end give additional flexibility, but at the price of
possibly increased complexity.

Also, performing the exchange of the attributes in-band with the EAP
authentication methods creates dependency on a specific feature with the
methods. Have you considered performing this outside EAP? For example,
via EAP lower layers.

The framework requires extensions to the AAA backend protocols. This is
briefly mentioned in the Security Considerations section, but eventually
I think it deserves some elaboration.

   3.2.1 Service Type Parameter
   ...

      0  PPP
      1  IEEE 802.11
      2  PANA
      3  IKEv2

I think this service type space, as defined in the draft, is not as
homogeneous. PPP, PANA, and IKEv2 (EAP lower layers) can be used on IEEE
802.11 (a link-layer type).

To me, there are the following views:

a- access type: remote (VPN-based) vs. local
b- EAP lower layer: PPP, IEEE 802.1X, PANA, IKEv2
c- Access technology: IEEE 802.11, DSL, GPRS, IP-in-IP tunnels (VPN),
etc.

Maybe we can see the service type from the view of (b).

Regards,

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Jari Arkko
> Sent: Friday, April 02, 2004 4:57 AM
> To: [email-masked]
> Cc: Pasi Eronen
> Subject: [eap] draft on authenticated service identities
> 
> 
http://www.arkko.com/publications/eap/draft-arkko-eap-service-identity-
> auth-00.txt
http://www.arkko.com/publications/eap/draft-arkko-eap-service-identity-
> auth-00.html

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Apr 2004 13:01:51 +0300

Thanks Alper for your comments. Some discussion

> authentication, and considering several service-related attributes is a

Good!

> possibly increased complexity.

There appears to be two issues in here: transfering the
information and checking it. I believe we should transfer
the information both ways, because its likely that there's
some case where, say, a lower layer is unable to transfer
some information that the AAA protocols can. Such piece of
information can not be checked, but it can still be valuable
to inform the other side about it for audit trail or other
purposes.

I think you are right about the check part, assuming that the
method is capable of actually informing the other end about
its decision. OTOH, it looks like having one side do the
check would add a roundtrip in methods that currently don't
inform the other end; I guess we wanted to make the extension
very simple & have minimal assumptions about the method otherwise,
even at the price of checking the same thing twice. Pasi, you
have comments on this?

> methods. Have you considered performing this outside EAP? For example,

Good question. I guess the overall conclusion is that *something*
has to be changed in order for the information to be exchanged.
Then we can talk about what that something is, and how easy
or hard changing it is compared to something else.

The good thing with the EAP approach is that you can keep your
lower layer unchanged. The good thing with the EAP lower layer
approach is that you can keep your EAP methods unchanged ;-)
Which one is better depends on your specific situation.

(In order to use the EAP lower layer for this, you'd
also have convert between the AAA and lower layer protocol
in the access point, and secure the information through
EAP generated keys (EMSK etc) so that the access point
can not change them. Alternatively, you could invent
some way of signing the lower layer advertisements that
already exist, through EAP-generated keys.)

> I think it deserves some elaboration.

That's right. The next revision intends to list also the AAA
mappings of the parameters.

> Maybe we can see the service type from the view of (b).

This is a valid comment as well.

--Jari

---

From: Alper Yegin <[email-masked]>
Date: Wed, 14 Apr 2004 12:06:01 -0700

> to inform the other side about it for audit trail or other

OK.

> inform the other end; 

If the check is performed by the AAA server, does it still add a
roundtrip?

> I guess we wanted to make the extension

Agreed.

Alper

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Apr 2004 08:14:16 +0300

> If the check is performed by the AAA server, does it still add a

I think so, because we need not just the check, but also a
way to communicate the result of the check to the other
end. OTOH, on _some_ environments having the AAA server
fail the authentication is enough. For instance, in 802.11i
if the AAA server fails, the AP will not get the MSK, and
the parties can't complete the 4-way handshake. Thus
eventually everyone knows there was a failure.

--Jari

---

From: Alper Yegin <[email-masked]>
Date: Thu, 15 Apr 2004 15:30:11 -0700

> fail the authentication is enough. 

Yes, this is what I'm thinking. Is this really only on some
environments?
If designed appropriately, the AAA server can perform the check as part
of (or before) the client-NAS authentication. Are there cases this is
not possible?

> For instance, in 802.11i

Alper