RFC Errata
Found 5 records.
Status: Verified (4)
RFC 4763, "Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)", November 2006
Source of RFC: INDEPENDENT
Errata ID: 1413
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-12
Verifier Name: Bob Braden
Date Verified: 2008-04-23
Section 3.2.6.1 says:
The KDF is a keyed hash function with key "Key" and operating on input "Label | Msg". The convention followed herein is that concatenation is denoted by |, FLOOR denotes the floor function, and [x...y] denotes bytes x through y.
It should say:
The KDF is a keyed hash function with key "Key" and operating on input "Label | Msg". The convention followed herein is that concatenation is denoted by |, CEIL denotes the ceiling function, and [x...y] denotes bytes x through y.
Notes:
The 'FLOOR' function is used where the 'CEILING' or 'CEIL' function is needed, to properly set the repetition count for partitioning a message into fixed-size blocks. The same error occurs in the code block at the end of Section 3.2.6.1.
Errata ID: 1414
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-12
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-05
Section 3.3.1 says:
Type
To be assigned
It should say:
Type
EAP-SAKE (=48)
Notes:
8) The explanation,
AT_ENCR_DATA
This attribute is optional to use in this message. The encrypted
data, if present, may contain an attribute AT_NEXT_TMPID,
containing the NAI the Peer should use in the next EAP
authentication.
should say:
| AT_ENCR_DATA (=128)
| This attribute is optional to use in this message. The cleartext
| form of the encrypted data, if present, may contain an attribute
AT_NEXT_TMPID, containing the NAI the Peer should use in the next
EAP authentication.
(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.
^^^^^^
(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.
Errata ID: 1416
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-12
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-05
The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.
(1) Section 3.1 -- word omission
The first bullet in Section 3.1, on mid-page 4, says:
v
| o It is based on well-established Bellare-Rogaway mutual
authentication protocol.
It should say:
vvvvv
| o It is based on the well-established Bellare-Rogaway mutual
authentication protocol.
BTW: Wouldn't that have deserved a proper reference ???
(2) Section 3.2.6.1 -- URGENT algorithmic correction
Unfortunately, Section 3.2.6.1 contains a bad legacy mistake.
Like a couple of related documents, it does not properly set
the repetition count needed for the partitioning of a message
into fixed-size blocks, by substituting the 'FLOOR' function
where the 'CEILING' or 'CEIL' function would be needed.
To most easily see what's wrong, try substituting Length := 16
(hence, a single 20-octet HMAC-SHA1 result is needed to cover
the requested size), and observe the controlling loop:
for i := 0 to FLOOR(Length/20)-1 do
becomes:
for i := 0 to FLOOR(16/20)-1 do
which is:
for i := 0 to 0-1 do
or:
for i := 0 to -1 do
and hence no H-SHA1 calls are ever performed.
The simple rule-of-thumb is:
- you need FLOOR if you want to fit fixed-size pieces into a bag;
- you need CEIL[ING] if you want to cover a bag with fixed-size pieces.
These are the changes to make the algorithm in Section 3.2.6.1 work
as intended:
In the first paragraph on page 16, where the RFC says:
The KDF is a keyed hash function with key "Key" and operating on
input "Label | Msg". The convention followed herein is that
| concatenation is denoted by |, FLOOR denotes the floor function, and
[x...y] denotes bytes x through y.
it should say:
The KDF is a keyed hash function with key "Key" and operating on
input "Label | Msg". The convention followed herein is that
| concatenation is denoted by |, CEIL denotes the ceiling function,
and [x...y] denotes bytes x through y.
The code block at the end of Section 3.2.6.1 :
KDF(Key, Label, Msg, Length)
R := [] ;; null string
| for i := 0 to FLOOR(Length/20)-1 do
| R := R | H-SHA1(Key, Label, Msg, i)
return R[0...(Length-1)]
should properly state:
KDF(Key, Label, Msg, Length)
R := [] ;; null string
| for i := 0 to CEIL(Length/20)-1 do
| R := R | H-SHA1(Key, Label, Msg, i)
return R[0...(Length-1)]
[ Note: I also have indented the statement making up the body
of the loop to cleraly identify this property. ]
(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!
(4) Section 3.3.1 -- lack of specification, and a word omission
Unfortunately, the RFC has not been cleaned up after IANA allocation
and remains unspecific und indeterminate on the protocol constant
(EAP method type) EAP-SAKE (=48).
In Section 3.3.1, the explanation:
Type
To be assigned.
should say:
Type
| EAP-SAKE (=48)
At the end of Section 3.3.1, the explanation:
Subtype
EAP-SAKE subtype: SAKE/Challenge, SAKE/Confirm, SAKE/Auth-Reject,
and SAKE/Identity. All messages of type "EAP-SAKE" that are not
| of these subtypes MUST silently discarded.
[...] ^
should say:
Subtype
EAP-SAKE subtype: SAKE/Challenge, SAKE/Confirm, SAKE/Auth-Reject,
and SAKE/Identity. All messages of type "EAP-SAKE" that are not
| of these subtypes MUST silently be discarded.
[...] ^^^^
(5) Section 3.3.2 -- format, and incomplete specification
The inadvertent blank line near the end of the table on page 24
has no functional meaning and hence should be deleted.
At the end of the section, below the table, add the sentence:
The attribute type values assigned by this specification (and
registered by the IANA) are listed in section 4.
Note:
Below, I have chosen to supply the missing values explicitely,
rather than proposinf to repeatedly add similar pointers to Sct. 4.
This seems to better serve the needs of the reader and hopefully
will aid the implementer as well.
(6) Section 3.3.3 -- lack of specification, and artwork improvement
For uniformity, *all* constant values should be made visible in
the message format diagrams.
The rationale of item (4) above applies as well.
The figure in Section 3.3.4, on page 26, contains the initial part:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Type=EAP-SAKE | Version=2 | Session ID | Subtype=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_RAND_S | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| ...
It should say:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code=1 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Type=EAP-SAKE | Version=2 | Session ID | Subtype=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_RAND_S | Length=18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| ...
The explanation:
Type
| EAP-SAKE
should say:
Type
| EAP-SAKE (=48)
At the end of the section, on page 27, the explanations:
| AT_RAND_S
The value field of this attribute contains the Server nonce RAND_S
parameter. The RAND_S attribute MUST be present in
EAP.Request/SAKE/Challenge.
| AT_SERVERID
The value field of this attribute contains the Server identifier
(e.g., a non-null terminated string). The AT_SERVERID attribute
SHOULD be present in EAP.Request/SAKE Challenge.
should say:
| AT_RAND_S (=1)
The value field of this attribute contains the Server nonce RAND_S
parameter. The RAND_S attribute MUST be present in
EAP.Request/SAKE/Challenge.
| AT_SERVERID (=5)
The value field of this attribute contains the Server identifier
(e.g., a non-null terminated string). The AT_SERVERID attribute
SHOULD be present in EAP.Request/SAKE Challenge.
(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)
(8) Section 3.3.6 -- lack of specification, and artwork improvement
As above ...
Also, a spurious separator line in the diagram should be deleted.
The figure in Section 3.3.6, on page 30, contains the initial part:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Type=EAP-SAKE | Version=2 | Session ID | Subtype=2 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_SPI_S | Length | SPI_S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_IV | Length | Initialization Vector ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| ...
It should say:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code=1 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Type=EAP-SAKE | Version=2 | Session ID | Subtype=2 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_SPI_S | Length | SPI_S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_IV | Length | Initialization Vector ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| ...
On page 31, the explanation:
Type
| EAP-SAKE
should say:
Type
| EAP-SAKE=48
The subsequent explanation headlines:
| AT_SPI_S
| AT_IV
| AT_MSK_LIFE
| AT_MIC_S
should be amended to say, respectively:
| AT_SPI_S (=7)
| AT_IV (=129)
| AT_MSK_LIFE (=132)
| AT_MIC_S (=3)
Finally, the explanation,
AT_ENCR_DATA
This attribute is optional to use in this message. The encrypted
data, if present, may contain an attribute AT_NEXT_TMPID,
containing the NAI the Peer should use in the next EAP
authentication.
should say:
| AT_ENCR_DATA (=128)
| This attribute is optional to use in this message. The cleartext
| form of the encrypted data, if present, may contain an attribute
AT_NEXT_TMPID, containing the NAI the Peer should use in the next
EAP authentication.
(9) Section 3.3.7 -- lack of specification, and artwork improvement
As above ...
The figure in Section 3.3.7, on page 32, contains the initial part:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Type=EAP-SAKE | Version=2 | Session ID | Subtype=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_MIC_P | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIC_P |
| ...
It should say:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code=2 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Type=EAP-SAKE | Version=2 | Session ID | Subtype=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_MIC_P | Length=18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIC_P |
| ...
The explanation:
Type
| EAP-SAKE
should say:
Type
| EAP-SAKE (=48)
And on page 33, the explanation headlines:
| AT_MIC_P
| AT_PADDING
should be amended to say, respectively:
| AT_MIC_P (=4)
| AT_PADDING (=130)
(10) Section 3.3.8 -- lack of specification, and artwork improvement
As above ...
The figure in Section 3.3.8, on page 33, says:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Type=EAP-SAKE | Version=2 | Session ID | Subtype=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code=2 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Type=EAP-SAKE | Version=2 | Session ID | Subtype=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The explanation:
Type
| EAP-SAKE
should say:
Type
| EAP-SAKE (=48)
(11) Section 3.3.9 -- lack of specification, and artwork improvement
As above ...
The figure in Section 3.3.9, on page 34, contains the initial part:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Type=EAP-SAKE | Version=2 | Session ID | Subtype=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code=1 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Type=EAP-SAKE | Version=2 | Session ID | Subtype=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
On page 35, the explanation:
Type
| EAP-SAKE
should say:
Type
| EAP-SAKE=48
The subsequent explanation headlines:
| AT_PERM_ID_REQ
| AT_ANY_ID_REQ
| AT_SERVERID
should be amended to say, respectively:
| AT_PERM_ID_REQ (=10)
| AT_ANY_ID_REQ (=9)
| AT_SERVERID (=5)
(12) Section 3.3.10 -- lack of specification, and artwork improvement
As above ...
The figure in Section 3.3.10, on page 36, contains the initial part:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Type=EAP-SAKE | Version=2 | Session ID | Subtype=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code=2 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Type=EAP-SAKE | Version=2 | Session ID | Subtype=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The explanation:
Type
| EAP-SAKE
should say:
Type
| EAP-SAKE (=48)
And on page 37, the explanation headline:
AT_PEERID
should be amended to say:
AT_PEERID (=6)
(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
Errata ID: 845
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-12
Verifier Name: Bob Braden
Date Verified: 2008-04-23
Section 3.1 says:
o It is based on well-established Bellare-Rogaway mutual
authentication protocol.
It should say:
o It is based on the well-established Bellare-Rogaway mutual
authentication protocol.
Status: Rejected (1)
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.