Subject: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC2865 (4077)

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Sep 2014 20:27:07 +0200

AAA doctors,

What do you think of this?

Regards, Beonit

-------- Original Message --------
Subject: 	[Technical Errata Reported] RFC2865 (4077)
Date: 	Sun, 10 Aug 2014 07:57:02 -0700
From: 	RFC Errata System <[email-masked]>
To: 	<[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]>
CC: 	<[email-masked]>, <[email-masked]>

The following errata report has been submitted for RFC2865,
"Remote Authentication Dial In User Service (RADIUS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=2865&eid=4077

--------------------------------------
Type: Technical
Reported by: Axel Luttgens <[email-masked]>

Section: 3

Original Text
-------------
       Response Authenticator

          The value of the Authenticator field in Access-Accept, Access-
          Reject, and Access-Challenge 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 Access-Request packet, and
          the response Attributes, followed by the shared secret.  That
          is, ResponseAuth =
          MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
          denotes concatenation.

Corrected Text
--------------
       Response Authenticator

          The value of the Authenticator field in Access-Accept, Access-
          Reject, and Access-Challenge packets is called the Response
          Authenticator, and contains a one-way MD5 hash calculated over
          a stream of octets consisting of: the response Code field, the
          Identifier, the response Length, the Request Authenticator, the
          response Attributes, and finally the shared secret.
          That is, ResponseAuth =
          MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
          denotes concatenation.

Notes
-----
This sentence fragment "[...] consisting of: the RADIUS packet, [...]" tends to imply one is considering either the Access-Request packet, or the reply packet being under construction.

But this is inconsistent with the idea of having the the MD5 hash calculated over both the Request Authenticator and the response Attributes...

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC2865 (draft-ietf-radius-radius-v2-06)
--------------------------------------
Title               : Remote Authentication Dial In User Service (RADIUS)
Publication Date    : June 2000
Author(s)           : C. Rigney, S. Willens, A. Rubens, W. Simpson
Category            : DRAFT STANDARD
Source              : Remote Authentication Dial-In User Service
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 17 Sep 2014 15:16:50 -0400

> What do you think of this?

  I don't see this as having caused problems in the last 20 years.  So
the text is likely fine.

> This sentence fragment "[...] consisting of: the RADIUS packet, [...]" tends to imply one is considering either the Access-Request packet, or the reply packet being under construction.

  Well, no.  It should be interpreted as "the RADIUS packet under
construction".  I don't see a reason why it would refer to some other
packet.

> But this is inconsistent with the idea of having the the MD5 hash calculated over both the Request Authenticator and the response Attributes...

  Which is why the Request Authenticator is specifically called out as
being different.

  The MD5 calculation can be done on each field individually.  i.e. it
can be done directly on the Request Authenticator from the
Access-Request packet.

  In practice, implementations usually just memcpy() the Request
Authenticator to the Response Authenticator, and do an MD5 over the
entire packet.  This is faster than doing it field by field.

  But there is no *requirement* for that to be done.

  His suggested text changes:

... the RADIUS packet, beginning with the Code field, including the
Identifier, the Length, the Request Authenticator field from the
Access-Request packet, and the response Attributes

  To:

.. the response Code field, the Identifier, the response
Length, the Request Authenticator, the response Attributes

  Note he doesn't say "the response Identifier".  So the suggested
change is still ambiguous.

  I don't see the "RADIUS packet" as being ambiguous.  The Response
Authenticator is being calculated for a specific packet, and the term
"RADIUS packet" clearly refers to the packet under construction.  I
don't see it as reasonable to assume that "RADIUS packet" in this
context refers to some *other* packet.

  Alan DeKok.

---

From: Benoit Claise <[email-masked]>
Date: Mon, 22 Sep 2014 12:27:59 +0200

Thanks Alan,

Including Axel in cc, just in case he wants to reply.
Otherwise, I lean towards "rejected" and will do so in a couple of days.

Regards, Benoit

---

From: Alan DeKok <[email-masked]>
Date: Mon, 22 Sep 2014 17:55:45 -0400

Axel Luttgens wrote:
> Assuming "the RADIUS packet" designates the packet under construction, it can't include the "Request Authenticator field from the Access-Request packet".

  Which is why the text specifically calls it out as being from
*another* packet.

> In which case "the RADIUS packet" must designate the request packet; but then it can't include the response Attributes.

  I don't see how that interpretation is possible.

> So, maybe is "the RADIUS packet" just a leftover of an erroneous copy/paste operation and should be removed;

  No.

> but then, why not take the opportunity be explicit about the various parts involved in the calculation, for the sake of clarity and an easier reading?

  The text has been OK for about twenty years.  I don't think there are
critical issues with it that prevent implementations from being written.

> Isn't the value of the response Identifier copied from the identifier of the request that triggered the response?

  You're missing my point.

  Your text said:

	Identifier
	RESPONSE Code
	RESPONSE Length
	..

  i.e. you carefully qualified every field with the word RESPONSE.  But
you didn't do it for the Identifier field.  So... the same ambiguity
applies.  Your suggested text could be taken to mean it refers to the
REQUEST authenticator.

> In which case there is a single value to consider, and adding a qualifier to "the Identifier" would have brought ambiguity.

  If that's true, why add the qualifier "Response" to all of the OTHER
fields of the response packet?

  You're trying to have it both ways.  Stating that some fields
*require* the "Response" qualifiers, but that others in the same packet
don't require that qualifier.

  It makes no sense.  Either use "Response" for ALL fields of the
response packet, or NONE of them.

  Alan DeKok.