RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 2548, "Microsoft Vendor-specific RADIUS Attributes", March 1999

Source of RFC: radius (ops)

Errata ID: 4369
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Alan DeKok
Date Reported: 2015-05-19
Rejected by: Benoit Claise
Date Rejected: 2015-09-14

Section 2.4.1 says:

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.

It should say:

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.

Report New Errata



Advanced Search