Re: Review of draft-ietf-radext-status-server-05 (Part II)

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> Sections 2.1 and Section 2.2
> 
> Section 2 explains the unique properties of Status-Server and why a
> RADIUS client might want to use it.  RFC 2865 Section 2.6
> explains why "keepalives" are a bad idea.  Presumably this advice
> applies to both RADIUS Access-Request and Accounting-Request
> keepalives.  Given that, Sections 2.1 and 2.2 belabor the point.  I'd
> suggest that they be deleted.

  I think that they have some use.  There are a number of
implementations which "overload" Access-Requests for all kinds of
functionality.  Having an explanation as to why this is bad can help
guide implementors.

> Section 2.3
> 
> I would suggest deleting this section as well.

  OK.

> Section 2.3.1
> 
> My advice is to incorporate the material in this section into Section 2
> (To be retitled Overview).

  Done.

> Section 3
> 
>      Response Authenticator
> 
>          The value of the Authenticator field in Access-Accept, or
>          Accounting-Response packets is called the Response
>          Authenticator, and contains a one-way MD5 hash calculated over
>          a stream of octets consisting of: the RADIUS packet, beginning
>          with the Code field, including the Identifier, the Length, the
>          Request Authenticator field from the Status-Server packet, and
>          the response Attributes (if any), followed by the shared
>          secret.  That is, ResponseAuth =
>          MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
>          denotes concatenation.
> 
> [BA] Why is this material here?  If you need it at all (I don't think so), you can just reference
> RFC 2865 and/or 2866. 

  Otherwise there will be confusion over how to calculate it.  The other
RFCs define how the Response Authenticator is calculated for response
packets.  It's not a *bad* idea to include similar text here.

>    Status-Server packets MAY include NAS-Identifier, and one of NAS-IP-
>    Address or NAS-IPv6-Address.  These attributes are not necessary for
>    the operation of Status-Server, but may be useful information to a
>    server that receives those packets.
> 
> [BA] You might say that the server MUST ignore other attributes. 

  OK.

>    Other attributes SHOULD NOT be included in a Status-Server packet.
>    User authentication credentials such as User-Password, CHAP-Password,
>    EAP-Message, etc. MUST NOT appear in a Status-Server packet sent to a
>    RADIUS authentication port.  User or NAS accounting attributes such
>    as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets, etc.  MUST
>    NOT appear in a Status-Server packet sent to a RADIUS accounting
>    port.
> 
> [BA] Also, presumably User-Name is not included (relevant to the point about realms made earlier). 

  Yes.  I'll add that in.

  Alan DeKok.

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