RFC Errata
RFC 4763, "Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)", November 2006
Source of RFC: INDEPENDENT
Errata ID: 1415
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-12
Rejected by: Bob Braden
Date Rejected: 2008-04-24
(3) Section 3.2.8.2 -- clarification needed Within Section 3.2.8.2, the second paragraph on page 20 says: The default encryption algorithm, as described in Section 3.2.8.3, requires the length of the plaintext to be a multiple of 16 bytes. The sender MAY need to include the AT_PADDING attribute as the last | attribute within the value field of the AT_ENCR_DATA attribute. The length of the padding is chosen so that the length of the value field of the AT_ENCR_DATA attribute becomes a multiple of 16 bytes. The AT_PADDING attribute SHOULD NOT be included if the total length of other attributes present within the AT_ENCR_DATA attribute is a multiple of 16 bytes. The length of the AT_PADDING attribute includes the Attribute Type and Attribute Length fields. The actual pad bytes in the value field are set to zero (0x00) on sending. The recipient of the message MUST verify that the pad bytes are zero after decryption and MUST silently discard the message otherwise. It should say: The default encryption algorithm, as described in Section 3.2.8.3, requires the length of the plaintext to be a multiple of 16 bytes. The sender MAY need to include the AT_PADDING attribute as the last | attribute within the plaintext of the value field of the AT_ENCR_DATA attribute. The length of the padding is chosen so that the length of the value field of the AT_ENCR_DATA attribute becomes a multiple of 16 bytes. The AT_PADDING attribute SHOULD NOT be included if the total length of other attributes present within the AT_ENCR_DATA attribute is a multiple of 16 bytes. The length of the AT_PADDING attribute includes the Attribute Type and Attribute Length fields. The actual pad bytes in the value field are set to zero (0x00) on sending. The recipient of the message MUST verify that the pad bytes are zero after decryption and MUST silently discard the message otherwise. Note: The proper distinction between the plaintext and the ciphertext version of fields that are encrypted in its on-the-wire form should be heavily emphasized; neglecting this distinction can lead to significant interoperability problems and catastrophic cryptographic failures! (7) Section 3.3.5 -- lack of specification, and artwork improvement As above ... The figure in Section 3.3.5, on page 28, contains the initial part: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=EAP-SAKE | Version=2 | Session ID | Subtype=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_RAND_P | Length = 18 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ... It should say: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=EAP-SAKE | Version=2 | Session ID | Subtype=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_RAND_P | Length=18 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ... On page 29, the explanation: Type | EAP-SAKE should say: Type | EAP-SAKE=48 And the subsequent explanation headlines: | AT_RAND_P | AT_PEERID | AT_SPI_P | AT_MIC_P should be amended to say, respectively: | AT_RAND_P (=2) | AT_PEERID (=6) | AT_SPI_P (=8) | AT_MIC_P (=4) (13) Section 4 -- lack of specification The first paragraph of Section 4 (on page 37) says: | IANA allocated a new EAP Type for EAP-SAKE. ^ It should say: | IANA allocated a new EAP Type, 48, for EAP-SAKE. ^^^^^^ (14) Section 5.5 -- spelling and terminology 'Server' and 'Peer' are distinguished roles of EAP entities. Therefore, when talking about both participants in an EAP session, the term 'Peer' (in headline case) should not be used to avoid confusion. Therefore, the last paragraph of Section 5.5, on page 40, that says, [...] Thus, the recipient of an EAP message can be assured that | the message it just received is the one just sent by the other Peer and not a replay, since it contains a valid MIC of the recipient's | nonce and the other Peer nonce. As before, the extent of replay protection is commensurate with the security of the KDF used to derive the MIC, the length and entropy of the shared secret used by the KDF, and the length of the MIC. should better say: [...] Thus, the recipient of an EAP message can be assured that | the message it just received is the one just sent by the other party and not a replay, since it contains a valid MIC of the recipient's | nonce and the other party's nonce. As before, the extent of replay protection is commensurate with the security of the KDF used to derive the MIC, the length and entropy of the shared secret used by the KDF, and the length of the MIC. (15) Section 8.1 -- outdated Normative Reference On page 45, the ref. [SHA1] should better point to the current version, "FIPS 180-2 (with Change Notice)", February 2004.
It should say:
[not submitted]
Notes:
from pending
--VERIFIER NOTES--
Repeticious and unnecessary reports.