On Oct 1, 2024, at 1:10 PM, Julien Rische <jrische@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.