RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search