eap Mailing List: Re: draft on authenticated service identities

[Yoshihiro Ohba (yohba]

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