From jrische at redhat.com Tue Oct 1 11:50:02 2024 From: jrische at redhat.com (Julien Rische) Date: Tue, 1 Oct 2024 17:50:02 +0200 Subject: Message-Authenticator depending of request/response code Message-ID: Hello everyone, 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." 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." However, I see that the FreeRADIUS server seems to be generating Message-Authenticators for additional packet codes[4]. 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. 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? Thank you in advance, Julien Rische Red Hat, Inc. [1] https://github.com/krb5/krb5/pull/1370 [2] https://datatracker.ietf.org/doc/html/rfc2869 [3] https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius-03 [4] https://github.com/FreeRADIUS/freeradius-server/blob/4312a2df8e0829c87811f42da7591a852350c068/src/protocols/radius/base.c#L367-L386 From jrische at redhat.com Tue Oct 1 13:10:25 2024 From: jrische at redhat.com (Julien Rische) Date: Tue, 1 Oct 2024 19:10:25 +0200 Subject: Message-Authenticator depending of request/response code Message-ID: Hello everyone, 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." 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." However, I see that the FreeRADIUS server seems to be generating Message-Authenticators for additional packet codes[4]. 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. 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? Thank you in advance, Julien Rische Red Hat, Inc. [1] https://github.com/krb5/krb5/pull/1370 [2] https://datatracker.ietf.org/doc/html/rfc2869 [3] https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius-03 [4] https://github.com/FreeRADIUS/freeradius-server/blob/4312a2df8e0829c87811f42da7591a852350c068/src/protocols/radius/base.c#L367-L386 From aland at deployingradius.com Tue Oct 1 14:04:26 2024 From: aland at deployingradius.com (Alan DeKok) Date: Tue, 1 Oct 2024 14:04:26 -0400 Subject: Message-Authenticator depending of request/response code In-Reply-To: References: Message-ID: <5C064BD1-C9C0-431F-85C8-709267A45199@deployingradius.com> On Oct 1, 2024, at 1:10 PM, Julien Rische 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.