Subject: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata

From: "Euchner, Martin" <[email-masked]>
Date: Tue, 31 Oct 2006 10:55:44 +0100

Dear MIKEY experts,

Please find below a proposed errata for recently published RFC 4650 "MIKEY DHHMAC".

I've reviewed the proposal and I consider all the proposed corrections/improvements correct.

Can we have a mailing list discussion and agreement within MSEC, if the proposed errata is acceptable?

With kind regards

Martin Euchner.

-----Original Message-----
From: Martin Euchner [mailto:[email-masked]] 
Sent: Dienstag, 17. Oktober 2006 17:55
To: Euchner, Martin
Subject: FW: RFC 4650 errata

From: Alfred HÎnes <[email-masked]>
To: [email-masked], [email-masked]
Subject: RFC 4650 errata
Date: Fri, 13 Oct 2006 16:19:07 +0200 (MESZ)

Hello,
reading the recently published RFC 4650 (MIKEY DHHMAC), I found
a couple of textual flaws that might be noted as RFC errata.

The items below are presented in textual order of occurrence.
Only items (14) and (15) below are considered serious.

(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:

|  There is work done in the IETF to develop key management schemes.
    [..]

(2) typo

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:

       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.

(3) 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:

    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.

(4) typo

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:

    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];

(5) message syntax notation

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
                     <----------------------

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
                     <----------------------

(5')

  Similar corrections would be suitable in Section 3.1 for Figure 2,
on page 10.

(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:

                                         [...].  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.

(7) extraneous (duplicate) word

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:

|  Other next payload values defined in [2] SHALL not be applied to
    DHHMAC.

(8) missing comma, causing possible mis-interpretation
     [similar to item (6) above]

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:

           [...].  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.

(9) 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:

|  * Eavesdropping of other, transmitted keying information: The DHHMAC
      protocol does not explicitly transmit the TGK at all.  [...]

(10) 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:

    * 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).  [...]

(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:

    * 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.  [...]

(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:

|                                              [...].  This is left for
      further study.

(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.

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 and certificate revocation methods with
      additional roundtrips.

(14) outdated Informative Reference

Once more: This RFC as well references the now-outdated RFC 1750.
All new RFCs should refer to BCP 106, RFC 4086, instead of RFC 1750!

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.

(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:

    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.  [...]

Best regards,
   Alfred HÎnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Oct 2006 10:36:51 -0600

Thanks.

I can't help to think that if it had some many glitches, maybe we
issued the RFC too fast. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Euchner, Martin
> Sent: Tuesday, October 31, 2006 1:56 AM
> To: [email-masked]; Euchner, Martin; [email-masked]
> Subject: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata
> 
> Dear MIKEY experts,
> 
> Can we have a mailing list discussion and agreement within 
> MSEC, if the proposed errata is acceptable?
> 
> With kind regards
> 
> Martin Euchner.
> 
> 
> |                                              [...].  This 
> is left for

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 31 Oct 2006 08:53:59 -0800

Nearly all of these are editorial and IMO don't quite need to be done, I think.