Re: [AAA-DOCTORS] [Errata Rejected] RFC2548 (4369)

[Benoit Claise <[e-mail]>]

Alan,

Let's solve that on the AAA-doctors.
Kathleen and I are waiting for the outcome of your discussion.

Regards, Benoit
>    While the comment about 24 octets vs 32 is correct and appreciated, there are still open issues.
>
>    User-Password is not supposed to contain embedded zeros.  It is padded out to a multiple of 16 octets in length.  BUT there is no explicit "length" field in the attribute, unlike Tunnel-Password.
>
>    Therefore, implementations determine the length by going to the end of the decrypted buffer, and looking for the first non-zero character.
>
>    That method does not work for MS-CHAP-MPPE-Keys.  That attribute is binary, and is explicitly allowed to contain embedded zeros.  Therefore the above method for determining length doesn't work.  There is a 1/256 chance that the last octet of the NT key is, in fact, zero.
>
>    The technical errata points out that the length of the decoded attribute MUST be manually set to 24.  The "normal" method of looking for a non-zero octet doesn't work.
>
> On Sep 14, 2015, at 6:31 AM, RFC Errata System <[e-mail]> wrote:
>
>> The following errata report has been rejected for RFC2548,
>> "Microsoft Vendor-specific RADIUS Attributes".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=2548&eid=4369
>>
>> --------------------------------------
>> Status: Rejected
>> Type: Technical
>>
>> Reported by: Alan DeKok <[e-mail]>
>> Date Reported: 2015-05-19
>> Rejected by: Benoit Claise (IESG)
>>
>> Section: 2.4.1
>>
>> Original Text
>> -------------
>> The Keys field MUST be encrypted by the RADIUS server using the
>> same method defined for the User-Password Attribute [3].  Padding
>> is required because the method referenced above requires the field
>> to be encrypted to be a multiple of sixteen octets in length.
>>
>> Corrected Text
>> --------------
>> The Keys field MUST be encrypted by the RADIUS server using the
>> same method defined for the User-Password Attribute [3].  Padding
>> is required because the method referenced above requires the field
>> to be encrypted to be a multiple of sixteen octets in length.
>>
>> We note that the encryption method for the User-Password attribute
>> does not contain a field describing the length of the decrypted data.
>>   Despite this, the User-Password attribute contains data which is
>> variable length.  The length of that data is commonly determined by
>> looking for either the end of the data, or the first zero octet in the
>> data, whichever comes first.
>>
>> That practice cannot be used here, as the Keys field can contain
>> embedded zero octets.  This means that the length of the decrypted
>> data MUST be set explicitly to 32 octets for this attribute.
>>
>> Notes
>> -----
>> re: MS-CHAP-MPPE-Keys "obfuscation"
>> --VERIFIER NOTES--
>> Section 2.4.1 describes 32 octets of content, which *include* padding.
>>
>> The decrypted data is thus less than 32 octets. The ASCII art in that sections shows 64 bit of padding in the end, meaning it's only 24 octets of decrypted keys.
>>
>> --------------------------------------
>> RFC2548 (draft-ietf-radius-ms-vsa-01)
>> --------------------------------------
>> Title               : Microsoft Vendor-specific RADIUS Attributes
>> Publication Date    : March 1999
>> Author(s)           : G. Zorn
>> Category            : INFORMATIONAL
>> Source              : Remote Authentication Dial-In User Service
>> Area                : Operations and Management
>> Stream              : IETF
>> Verifying Party     : IESG
>>