AW: interpreted vs un-interpreted attributes; RADEXT charter, Tak e 8

["Beck01, Wolfgang" <BeckW@t-systems.com>]

Dave wrote:
> However, I think the key issues with consensus acceptance of
> strings is whether they fall into one of two cases: (a) limited parsing
> is absolutely required, as in the case of NAI, or (b) RADIUS doesn't
> *ever* parse the strings, it passes them as opaque "binary blobs" to
> some other protocol, as in the case of EAP-Message.  In order to qualify
> as "some other protocol", the elements, syntax and semantics of that
> protocol can't be defined in a RADIUS or Diameter RFC.

I'd like to modify your classification of RADIUS attributes a bit. We have
1) RADIUS attributes that must interpreted by the RADIUS server
2) RADIUS attributes where the RADIUS server just looks up/fills in values
from a database.

Your compatibility concerns are justified for type 2) attributes. Type 1)
attributes are interpreted anyway, so structured string attributes do
not any harm. CHAP and NAI are examples for type 1) attributes. In many
cases EAP falls in this category, too. It depends on the architecture
of RADIUS server software.

I've considered EAP for the HTTP digest problem. However, the idea of EAP
is that supplicants speak EAP and the NAS just tunnels it to the RADIUS
server. Unfortunately todays' SIP clients don't support EAP, so the NAS
would have to put HTTP Digest parameters into a fresh EAP message. It
would work, but I am not sure whether EAP people would like it.

Wolfgang

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