RE: IESG review DISCUSS on draft-ietf-radext-management-authorization-06.txt

["Dave Nelson" <d.b.nelson@comcast.net>]

Pasi Eronen writes...  

> > The NAS is not expected to know what level of access the user is
> > "asking for", other than perhaps that an SSH sub-system is involved.
> > That's purely a matter of implementation detail, BTW, and is not
> > being standardized.
> >
> > The RADIUS server is expected to provision the appropriate level of
> > access for the user, based on the user's authorization profile
> > stored in the server's database (or otherwise obtained by the
> > server). The server may use optional (recommended) hint attributes
> > in the Access-Request message that identify the NAS in question and
> > the type of interface used, e.g. a virtual terminal connection, in
> > conjunction with the user's authorization profile, in making its
> > access rights decision.
> >
> > After discussion on the RADEXT mailing list and at IETF-74, it does
> > not appear that any change to the draft is required.
> 
> The situation for Access-Accept (the important part) is clear, and
> I guess for the hints in Access-Request, we can leave it
> implementation-specific... (like many other parts in RADIUS :-)

The use of appropriate hint attributes in the Access-Request is RECOMMENDED,
but the NAS can only hint what it knows.  It knows how the session "arrived"
i.e. over what mechanism.  It does not know the intent of the human at the
other end of the connection.  I think this is the best we can reasonably do.

> > Discussion on this issue on the RADEXT mailing list and at IETF-74
> > yielded the following observations.  These attributes are not
> > required for use in management access by RFC 2865 and RFC 2869, and
> > the authors don't think we want this draft to update those RFCs.
> > The variation in the format of the NAS-Port and Calling-Station-Id
> > attributes among different implementations has been an issue for a
> > long time.  It's probably an interesting topic for a separate work
> > item, but likely doesn't belong in this draft.  It does not appear
> > that any change to the draft is required.
> 
> Could you provide pointers to the RADEXT mailing list discussions?
> I couldn't find anything in the archive, and the IETF74 minutes don't
> mention anything either.

I'll search for the mail message(s) when I get a bit more time.  It was
presented in the slide deck at IETF-74 the proposed resolution to this
issue.  No one suggested we do otherwise.

> To the degree the source IP/port is just for human consumption
> (e.g. troubleshooting or forensics), it's probably OK to leave the
> contents implementation-specific.
> 
> But if they're used for something else, to me it seems that this draft
> would be the right place to make some recommendations (not necessarily
> requirements that would update 2865/2869) for the management
> protocols listed here. (Not for any other use of RADIUS, of course.)

The attributes that have variability are the NAS-ID and NAS-Port-ID, which
are basically as you have indicated -- human readable strings with no
specific recommended format.  I have to think that these attributes were (a)
intended for use in accounting, where they are simply logged verbatim for
humans to inspect later on or (b) were intended for use in authentication
and/or or authorization decisions, in some vendor-specific fashion.  The
RFCs don't give us any guidance here.

If there are (b) usages, it might be nice to standardize them someday.  The
point we were making was that it's not directly related to the NAS
Management Authorization work, and it's something that may be very difficult
to achieve consensus on, given the large diversity of implementations over a
large number of years.  In sort, the authors feel that it would be
unreasonable to hold *this* draft accountable for solving that problem.

Regards,

Dave Nelson



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