errata logo graphic

Found 15 records.

Status: Verified (1)

RFC4650, "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", September 2006

Source of RFC: msec (sec)

Errata ID: 2387

Status: Verified
Type: Technical

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)

RFC4650, "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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Report New Errata