RFC Errata
Found 15 records.
Status: Verified (1)
RFC 4650, "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", September 2006
Source of RFC: msec (sec)
Errata ID: 2387
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Verifier Name: Tim Polk
Date Verified: 2010-07-20
(15) typo -- results in wrong Endpoint identifier specified The 3rd paragraph of Appendix A, on page 25, says: To establish a call, it is assumed that endpoint B has obtained permission from the gatekeeper (not shown). Endpoint B as the caller builds the MIKEY-DHHMAC I_message (see section 3) and sends the I_message encapsulated within the H.323-SETUP to endpoint A. A | routing gatekeeper (GK) would forward this message to endpoint B; in case of a non-routing gatekeeper, endpoint B sends the SETUP directly to endpoint A. [...]
It should say:
It should say: To establish a call, it is assumed that endpoint B has obtained permission from the gatekeeper (not shown). Endpoint B as the caller builds the MIKEY-DHHMAC I_message (see section 3) and sends the I_message encapsulated within the H.323-SETUP to endpoint A. A | routing gatekeeper (GK) would forward this message to endpoint A; in case of a non-routing gatekeeper, endpoint B sends the SETUP directly to endpoint A. [...]
Notes:
from pending
Status: Held for Document Update (14)
RFC 4650, "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", September 2006
Source of RFC: msec (sec)
Errata ID: 2377
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
(6) missing comma, causing possible mis-interpretation
The last sentence of Section 3, at the bottom of page 9, says:
[...]. The HMAC SHALL be
computed over the entire message, excluding the MAC field using
auth_key; see also section 4.2.
It should say:
It should say:
[...]. The HMAC SHALL be
| computed over the entire message, excluding the MAC field, using
auth_key; see also section 4.2.
or perhaps even better and clearer:
[...]. The HMAC SHALL be
| computed (using auth_key) over the entire message excluding the MAC
| field; see also section 4.2.
Notes:
from pending
Errata ID: 2379
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
missing comma, causing possible mis-interpretation
The last sentence of the second paragraph of Section 4.2,
on page 12, says:
[...]. The HMAC is then calculated over the entire MIKEY
message, excluding the MAC field using auth_key as described in [2]
section 5.2, and then stored within the MAC field.
It should say:
It should say:
[...]. The HMAC is then calculated over the entire MIKEY
| message, excluding the MAC field, using auth_key as described in [2]
section 5.2, and then stored within the MAC field.
or perhaps even better and clearer:
| [...]. The HMAC is then calculated using auth_key, over the
| entire MIKEY message, excluding the MAC field, as described in [2]
section 5.2, and then stored within the MAC field.
Notes:
from pending
Errata ID: 33
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
(1) word omission In Section 1, the first text line on page 2 says: There is work done in IETF to develop key management schemes. [..]
It should say:
It should say: | There is work done in the IETF to develop key management schemes. [..]
Notes:
from pending
Errata ID: 2373
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
In Section 1, the last indented paragraph on page 4 says:
However, the Diffie-Hellman key agreement protocol is known for
its subtle security strengths in that it is able to provide full
perfect forward secrecy (PFS) and further have to both parties
actively involved in session key generation. This special
security property (despite the somewhat higher computational
costs) makes Diffie-Hellman techniques attractive in practice.
It should say:
It should say:
However, the Diffie-Hellman key agreement protocol is known for
its subtle security strengths in that it is able to provide full
| perfect forward secrecy (PFS) and further have both parties
actively involved in session key generation. This special
security property (despite the somewhat higher computational
costs) makes Diffie-Hellman techniques attractive in practice.
Errata ID: 2374
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
typo (line folding problem?) The second paragraph of Section 2, on page 7, says: DHHMAC is applicable in a peer-to-peer group where no access to a public-key infrastructure can be assumed to be available. Rather, pre- shared master secrets are assumed to be available among the entities in such an environment.
It should say:
It should say: DHHMAC is applicable in a peer-to-peer group where no access to a public-key infrastructure can be assumed to be available. Rather, | pre-shared master secrets are assumed to be available among the entities in such an environment.
Notes:
from pending
Errata ID: 2375
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
In Section 2.1, the last paragraph on page 7 says:
a) SIP [13] and SDP, where the encoded MIKEY messages are
encapsulated and transported in SDP containers of the SDP
offer/answer see RFC 3264 [27]) handshake, as described in [4];
It should say:
It should say:
a) SIP [13] and SDP, where the encoded MIKEY messages are
encapsulated and transported in SDP containers of the SDP
| offer/answer (see RFC 3264 [27]) handshake, as described in [4];
or perhaps even better:
a) SIP [13] and SDP, where the encoded MIKEY messages are
encapsulated and transported in SDP containers of the SDP
| offer/answer handshake (see RFC 3264 [27]), as described in [4];
Notes:
from pending
Errata ID: 2376
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Sean Turner
Date Held: 2010-07-30
Section 3 says:
Figure 1 in Section 3, on page 8, says:
Initiator Responder
I_message = HDR, T, RAND, [IDi], IDr,
{SP}, DHi, KEMAC
-----------------------> R_message = HDR, T,
[IDr], IDi, DHr,
DHi, KEMAC
<----------------------
It should say:
To avoid optional empty protocol elements,
it should perhaps better say:
Initiator Responder
| I_message = HDR, T, RAND, [IDi,] IDr,
{SP}, DHi, KEMAC
-----------------------> R_message = HDR, T,
| [IDr,] IDi, DHr,
DHi, KEMAC
<----------------------
Similar corrections would be suitable in Section 3.1 for Figure 2,
on page 10.
Notes:
error in message syntax notation:
Errata ID: 2378
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
Extraneous (duplicate) word error: In Section 4.1, the last sentence on page 11, says: Other defined next payload values defined in [2] SHALL not be applied to DHHMAC.
It should say:
It should say: | Other next payload values defined in [2] SHALL not be applied to DHHMAC.
Notes:
from pending
Errata ID: 2380
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
missing article:
The last paragraph on page 13, i.e. the 2nd bullet in Section 5.2, says:
* Eavesdropping of other, transmitted keying information: DHHMAC
protocol does not explicitly transmit the TGK at all. [...]
It should say:
It should say:
| * Eavesdropping of other, transmitted keying information: The DHHMAC
protocol does not explicitly transmit the TGK at all. [...]
Notes:
from pending
Errata ID: 2381
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
[missing "/"]
The 3rd paragraph on page 14, i.e. the 4th bullet in Section 5.2, says:
* Man-in-the-middle attacks: Such attacks threaten the security of
exchanged, non-authenticated messages. Man-in-the-middle attacks
usually come with masquerade and or loss of message integrity (see
below). [...]
It should say:
It should say:
* Man-in-the-middle attacks: Such attacks threaten the security of
exchanged, non-authenticated messages. Man-in-the-middle attacks
| usually come with masquerade and/or loss of message integrity (see
below). [...]
Notes:
from pending
Errata ID: 2382
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
(11) missing comma (potential for mis-interpretation)
The second paragraph on page 15 (within Section 5.2) says:
* Identity protection: Like MIKEY, identity protection is not a major
design requirement for MIKEY-DHHMAC, either; see [2]. No security
protocol is known so far that is able to provide the objectives of
DHHMAC as stated in section 5.3, including identity protection
within just a single roundtrip. [...]
It should say:
It should say:
* Identity protection: Like MIKEY, identity protection is not a major
design requirement for MIKEY-DHHMAC, either; see [2]. No security
protocol is known so far that is able to provide the objectives of
| DHHMAC as stated in section 5.3, including identity protection,
within just a single roundtrip. [...]
Notes:
from pending
Errata ID: 2383
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
(12) extraneous word
The 3rd paragraph on page 18 (within Section 5.3) says:
If a very high security level is desired for long-term secrecy of
the negotiated Diffie-Hellman shared secret, longer hash values may
be deployed, such as SHA256, SHA384, or SHA512 provide, possibly in
| conjunction with stronger Diffie-Hellman groups. This is left as
for further study.
It should say:
It should say:
| [...]. This is left for
further study.
Notes:
from pending
Errata ID: 2384
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
(13) extraneous words (left over from changing the sentence?)
The last lines on page 18 (within Section 5.3) say:
Public-key infrastructures may not always be available in certain
environments, nor may they be deemed adequate for real-time
multimedia applications when additional steps are taken for
certificate validation and certificate revocation methods with
additional roundtrips into account.
It should say:
The RFC should say:
Public-key infrastructures may not always be available in certain
environments, nor may they be deemed adequate for real-time
multimedia applications when additional steps are taken for
certificate validation or certificate revocation methods require
additional roundtrips.
Notes:
Minor edits to corrected text by Tim Polk.
Errata ID: 2386
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
(14) outdated Informative Reference This RFC references the now-outdated RFC 1750. All new RFCs should refer to BCP 106, RFC 4086, instead of RFC 1750!
It should say:
Item [8] in Section 8.2, at the bottom of page 22 of RFC 4650, should be replaced by the proper RFC-style citation for RFC 4086.
Notes:
from pending