Message-Authenticator depending of request/response code

[Alan DeKok]

On Oct 1, 2024, at 1:10 PM, Julien Rische <jrische at redhat.com> wrote:
> We are currently working on implementing RADIUS Message-Authenticator for MIT
> krb5[1] according to RFC2865[2] and draft-ietf-radext-deprecating-radius-03[3].
> 
> We are not sure about what packet codes we should generate and expect
> Message-Authenticator to verify for. In draft-ietf-radext-deprecating-radius-03
> we can read:
> 
> Section 5.2.1:
> 
>  "Clients MUST add Message-Authenticator to all Access-Request packets."

  That seems clear.

> Section 5.2.4:
> 
>  "Servers MUST add Message-Authenticator as the first attribute in all
>   responses to Access-Request packets. That is, all Access-Accept,
>   Access-Reject, Access-Challenge, and Protocol-Error packets."

  That's also clear.

> However, I see that the FreeRADIUS server seems to be generating
> Message-Authenticators for additional packet codes[4].

  No.

  That code is calculating the Request Authenticator, as per RFC 2865.

> We would like to enforce
> the use of Message-Authenticator as much as possible, but we are not sure if it
> is relevant for all packet codes.

  Follow the guidelines of draft-ietf-radext-deprecating-radius and RFC5997.

> Could you explain why this specific code set triggers Message-Authenticator
> generation in the FreeRADIUS server? And do you have any recommendations about
> the cases where we should generate Message-Authenticators to ensure
> compatibility with FreeRADIUS?

 Follow the guidelines of draft-ietf-radext-deprecating-radius and RFC5997.

  Message-Authenticator is required for:

Access-Request
Access-Accept
Access-Reject
Access-Challenge
Protocol-Error
Status-Server

  It is optional for other situations.   The server has code to calculate the correct value _if_ the administrator adds it to the packet.  But the server does not _automatically_ add it to any other packet.

  Alan DeKok.