eap Mailing List: Re: draft on authenticated service identities

[Jari Arkko (jari.arkko]

Thanks Alper for your comments. Some discussion
inline:

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

Good!

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

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?

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

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

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

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

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

This is a valid comment as well.

--Jari