Re: RADIUS Calling-Station-Id for WiMAX

[Stefan Winter <stefan.winter@restena.lu>]

Hi,

> All the rest is positioning in defense of one fielded implementation or the
> other.


Being in the lucky position of not having to defend any particular 
implementation, my two currency-neutral cents.

> The issue at hand is whether RFC 3580 created a "standard" for the
> on-the-wire encoding format of the Calling-Station-Id Attribute, and whether
> or not it matters that WiMAX adopted a different on-the-wire encoding.


Reading RFC3280:

3.21.  Calling-Station-Id

  For IEEE 802.1X Authenticators, this attribute is used to store the
  Supplicant MAC address in ASCII format (upper case only), with octet
  values separated by a "-".  Example: "00-10-A4-23-19-C0".

This sounds pretty definitive to me. I agree with Avi that there is no 
RFC2119 wording here, but nevertheless the wording is quite strong.

From what I've read over various RADIUS mailing lists over the last 
couple of years, the wording above didn't get the attention it should, 
where I also agree with Avi. Yes, there's - notation, : notation, 
capitals, no capitals, and now there's obviously also a binary encoding. 
People exchange funny regular expressions to convert from one format to 
another in various server products when MAC authentication is in use 
already now. Not anywhere near a homogenous situation.

That's why I have to disagree with Avi's point: "That is why I stated 
that it is best to keep the format in RADIUS in its lowest common form 
(binary) and do the conversion to a particular format at the last 
moment. It is less error prone - as you can see by all of these 
exchanges." - Why would the binary form be a "common form" across the 
RADIUS landscape? Or on the wire/less, given that you argued yourself 
that some 802 flavours use different formats than others?

I also have to disagree with another argument: that RFC3580 is only 
informational. Well technically it is, but that doesn't mean its content 
is void and can be disregarded. That would be a very dangerous path to 
follow. Take for example RFC3579: "RADIUS (Remote Authentication Dial In 
User Service) Support For Extensible Authentication Protocol (EAP)". 
This is informational "only" as well, but nevertheless a) important and 
b) implemented halfways thoroughly. If one were to dismiss informational 
status RFCs, we couldn't "legally" do EAP authentication at all.

Having said all that, there obviously is confusion about what to put 
into the attribute, and the attribute may need to be consumed by a AAA 
server to make authorisation decisions - so a normative, fixed-format 
answer would be a very good thing to have. Whichever is chosen, I don't 
really care. But it should be only *one* format.

Greetings,

Stefan Winter

--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>