eap Mailing List: Re: draft on authenticated service identities

[Jari Arkko (jari.arkko]

Yoshihiro Ohba wrote:

> Here is my comments on your draft:

Thanks for taking a look!

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

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.

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

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.

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

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

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

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

--Jari