eap Mailing List: RE: draft on authenticated service identities

[Alper Yegin (alper.yegin]

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

OK.

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

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

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

Agreed.

Alper


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