RFC Errata
Found 5 records.
Status: Verified (2)
RFC 2548, "Microsoft Vendor-specific RADIUS Attributes", March 1999
Source of RFC: radius (ops)
Errata ID: 420
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hans-Ake Lund
Date Reported: 2005-02-04
Verifier Name: Dan Romascanu
Date Verified: 2010-05-10
Section 2.7.9 says:
Description
The MS-Secondary-NBNS-Server Attribute is used to indicate the
address of the secondary DNS server to be used by the PPP peer.
It MAY be included in both Access-Accept and Accounting-Request
packets.
It should say:
Description
The MS-Secondary-NBNS-Server Attribute is used to indicate the
address of the secondary NetBIOS Name Server (NBNS) [18] server to
be used by the PPP peer. It MAY be included in both Access-Accept
and Accounting-Request packets.
Errata ID: 1607
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2008-11-18
Verifier Name: Dan Romascanu
Date Verified: 2010-05-10
Section 2.4.1 says:
The NT-Key sub-field is sixteen octets in length and contains the first sixteen octets of the hashed Windows NT password. The format of the plaintext Keys field is illustrated in the following diagram:
It should say:
The NT-Key sub-field is sixteen octets in length and contains the first sixteen octets of the hash of the hashed Windows NT password. The format of the plaintext Keys field is illustrated in the following diagram:
Notes:
See comments referring to RFC 2548 around line 1350 of:
http://github.com/alandekok/freeradius-server/tree/master/src%2Fmodules%2Frlm_mschap%2Frlm_mschap.c
This is interoperable with everything, including Windows.
Status: Held for Document Update (2)
RFC 2548, "Microsoft Vendor-specific RADIUS Attributes", March 1999
Source of RFC: radius (ops)
Errata ID: 3918
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kazuhiko Mino
Date Reported: 2014-03-14
Held for Document Update by: Benoit Claise
Date Held: 2014-03-17
Section 2.4.2 says:
Call the shared secret S, the pseudo-random 128-bit Request
Authenticator (from the corresponding Access-Request packet) R,
and the contents of the Salt field A. Break P into 16 octet
chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
Intermediate values b(1), b(2)...c(i) are required.
It should say:
Call the shared secret S, the pseudo-random 128-bit Request
Authenticator (from the corresponding Access-Request packet) R,
and the contents of the Salt field A. Break P into 16 octet
chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
Intermediate values b(1), b(2)...b(i) are required.
Errata ID: 3919
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kazuhiko Mino
Date Reported: 2014-03-14
Held for Document Update by: Benoit Claise
Date Held: 2014-03-17
Section 2.4.3 says:
Call the shared secret S, the pseudo-random 128-bit Request
Authenticator (from the corresponding Access-Request packet) R,
and the contents of the Salt field A. Break P into 16 octet
chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
Intermediate values b(1), b(2)...c(i) are required.
It should say:
Call the shared secret S, the pseudo-random 128-bit Request
Authenticator (from the corresponding Access-Request packet) R,
and the contents of the Salt field A. Break P into 16 octet
chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
Intermediate values b(1), b(2)...b(i) are required.
Status: Rejected (1)
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.