Re: Last Call: IANA Considerations for RADIUS to Proposed Standard

[Bernard Aboba <aboba@internaut.com>]

I agree with Glen that it would be best to encourage publication of
specifications for *all* of the Packet Types referred to in RFC 2882, not
just the ones used in draft-chiba-radius-dynamic-authorization-07.txt. In
fact, the -00 version of this draft only allocated the Packet Types for
draft-chiba, and no other ones.

However, we got two comments (one from Harald), asking to bring the draft
up to date with Packet Type usage as documented in RFC 2882; and another
comment requesting that we document usage of attributes not allocated by
IANA. In the -01 draft, we accepted the former comment, but rejected the
latter. Since much of the RADIUS attribute space was "appropriated" at one point
or another, recognizing that would leave few additional attributes left
for allocation by IANA. However, since only 51 of the available Packet
Types are being used noted in RFC 2882, there is more leeway here.






> IESG goes on precedent, but this sure sets a neat one: Loathe to publish
> your proprietary protocol?  Spec too lame for the Standards Track?  IANA
> allocation blocked by some pesky RFC?   No problem, just "update" that
> pesky RFC to include the numbers you need!  To give a couple of random (but
> telling) examples, draft-aboba-radius-iana-01.txt lists RFC 2882 as the
> reference for Type Codes 29, 30 and 32.  Here is the _entire_ text
> explaining these three Type Codes:
>
> 5.2.  Authentication Modes
>
>     Additional message types have been added to negotiate passcode
>     changes for token card servers.
>
>      - Next Passcode
>      - New PIN
>      - Password Expired
>
>     They allow the NAS or RADIUS server negotiate passcode changes with
>     an external security server.
>
> That's it.  If anyone would like to explain to me how to build independent,
> interoperable implementations (presumably the purpose of standards) for
> those RADIUS messages, I'd love to hear it.  Another example (also from RFC
> 2882, the cited reference in draft-aboba-radius-iana-01.txt):
>
> 5.1.  Password Change
>
>     Remotely requested password change operations were described and
>     proposed, but rejected by the working group.  None the less, the
>     feature is still deployed in a number of products.
>
>     Message types:
>
>      - Password Request
>      - Password Ack or Reject
>
> Here we have a set of messages (Type Codes 7-9) that were _rejected_ (right
> or wrong) by an IETF WG legitimized as if by magic!  What is the format of
> these messages?  What do they contain?  One would likely have to dig
> through the same set of vendor manuals as Dave Mitton did when he was
> writing RFC 2882 to find that out.  I hope that I have clarified my use of
> the terms "pathetic" and "lame" in my comment; however, my use of the word
> "perversion" may not be quite clear.  My usage of the word is derived from
> definition 2 of "pervert" in the Merriam-Webster Online Dictionary (hardly
> authoritative, but what the heck): "2 a : to divert to a wrong end or
> purpose : MISUSE b : to twist the meaning or sense of : MISINTERPRET
> synonym see DEBASE".
>
>
>
> >                 --Steve Bellovin, http://www.research.att.com/~smb (me)
> >                 http://www.wilyhacker.com (2nd edition of "Firewalls" book)
>