Subject: RFC 4380 - errata and other notes

From: Alfred Hönes <[email-masked]>
Date: Thu, 16 Mar 2006 13:13:03 +0100 (MEZ)

Hello,
I'd like to submit a few comments, and corrections for obvious
errata in the recently published RFC 4380 ("Teredo") authored
by you.  The subsequent items are ordered most important first,
according to my (subjective) ranking.

(1)  Inconsistency on cryptographic algorithm (MAC) requirements

Within section 5.2.2, on the upper half of page 21, RFC 4380 states:

   To maximize interoperability, this specification defines a default
   algorithm in which the authentication value is computed according the
|  HMAC specification [RFC2104] and the SHA1 function [FIPS-180].
   Clients and servers may agree to use HMAC combined with a different
   function, or to use a different algorithm altogether, such as for
   example AES-XCBC-MAC-96 [RFC3566].

   The default authentication algorithm is based on the HMAC algorithm
   according to the following specifications:

|  - the hash function shall be the SHA1 function [FIPS-180].
   - the secret value shall be the shared secret with which the client
     was configured.

Contrary to that, within Section 7.2.1, in the paragraph extending
from page 39 to page 40, the same RFC says:

   If the shared secret contains sufficient entropy, the attacker would
   have to defeat the one-way function used to compute the
   authentication value.  This specification suggests a default
<<page break>>
|  algorithm combining HMAC and MD5.  If the protection afforded by MD5
   was not deemed sufficient, clients and servers can agree to use a
   different algorithm, e.g., SHA1.

I have been educated repeatedly that Security Considerations in RFCs
contain normative content when describing protocol behaviour.
Therefore, it should not happen that text in Security Considerations
contradicts normative content of other sections of an RFC.

Regarding the well known security issues that make MD5 appear much
weaker than SHA-1, according to contemporary comprehension by the
cryptographic community, the former specification (Section 5.2.2)
seems to be the better choice.
I therefore strongly recommend to publish an Author's Errata Note
for RFC 4380 correcting Section 7.2.1, replacing the snippit above
by text conforming to the rules specified in Section 5.2.2, e.g.:

   If the shared secret contains sufficient entropy, the attacker would
   have to defeat the one-way function used to compute the
|  authentication value.  This specification defines a default algorithm
|  combining HMAC and SHA-1.  Clients and servers can agree to use a
|  different message authentication algorithm, e.g. AES-XCBC-MAC-96.
|  See Section 5.2.2 for details.

(2)  Incomplete IANA Considerations

Section 9 of RFC 4380, on page 50, says:

   This memo documents a request to IANA to allocate a 32-bit Teredo
   IPv6 service prefix, as specified in Section 2.6, and a Teredo IPv4
   multicast address, as specified in Section 2.17.

It should say:

|  On requests documented in this memo, IANA has allocated a 32-bit
|  Teredo IPv6 service prefix, as specified in Section 2.6, a Teredo
|  IPv4 multicast address, as specified in Section 2.17, and a Teredo
|  UDP Port number, as specified in Section 2.7.

Rationale:
As per publication of the RFC, these assignments *have been* performed
by the IANA; I propose modified wording reflecting this fact.
Apparently, an IANA assignment also has been performed on behalf of the
Teredo proposal as documented in Section 2.7; for completeness, this
assignment should be mentioned in the IANA Considerations section as
well.  This will also serve as an easy-to-find "pointer" for readers
looking for the purpose of the assignment found in the IANA registry.

(3)  Various typos

I have found a couple of apparent typos in RFC 4380.  The sub-items
 below are pre-formatted for easy inclusion into an RFC errata note.

(3.1) Section 5.2.2, page 21

The first paragraph on page 21 contains the sentence:

                                           [...].  Before transmission,
   the authentication value is computed according to the specified
   algorithm; on reception, the same algorithm is used to compute a
   target value from the content of the receive packet.  [...]

It should say:

                                           [...].  Before transmission,
   the authentication value is computed according to the specified
   algorithm; on reception, the same algorithm is used to compute a
|  target value from the content of the received packet.  [...]
                                               ^

(3.2) Section 5.2.3, page 23

The second paragraph on page 23 [numbered list item 4)] says:

      [...].  The client SHOULD reply with a unicast Teredo bubble, sent
   to the source IPv4 address and source port of the local discovery
   bubble; the IPv6 source address of the bubble will be set to local
   Teredo IPv6 address; [...]

It should say:

      [...].  The client SHOULD reply with a unicast Teredo bubble, sent
   to the source IPv4 address and source port of the local discovery
|  bubble; the IPv6 source address of the bubble will be set to the local
   Teredo IPv6 address; [...]
                                                                ^^^^

(3.3) Section 5.2.7, page 27

The long paragraph in the middle of page 27 says:

                                              [...].  If the secondary
   qualification fails, the interval determination procedure will not be
   used, and the interval value will remain to the default value, 30
   seconds.  [...]

It should say:

                                              [...].  If the secondary
   qualification fails, the interval determination procedure will not be
|  used, and the interval value will remain at the default value, 30
   seconds.  [...]
                                           ^^^^

(3.4) Section 5.2.9, page 30

The last paragraph of Section 5.2.9 says:

            [...]  The nonce value and the date at which the packet was
   sent will be documented in a provisional peer entry for the IPV6
   destination.  The ICMPv6 packet will then be sent [...]

It should say:

            [...]  The nonce value and the date at which the packet was
|  sent will be documented in a provisional peer entry for the IPv6
   destination.  The ICMPv6 packet will then be sent [...]
                                                               ^^^^

(3.5) Section 7.2, page 39

The last sentence of Section 7.2 says:

      [...]  The attacker may have one of two objectives: it may try to
   deny service to the Teredo client by providing it with an address
   that is in fact unreachable, or it may try to insert itself as a
   relay for all client communications, effectively enabling a variety
   of "man-in-the-middle" attack.

It should say:

      [...]  The attacker may have one of two objectives: it may try to
   deny service to the Teredo client by providing it with an address
   that is in fact unreachable, or it may try to insert itself as a
   relay for all client communications, effectively enabling a variety
|  of "man-in-the-middle" attacks.
                                ^

(4)  Formatting issue

RFC 4380 contains a striking number of spurious blank lines inserted
in the middle of running text, interrupting proper paragraph formating.

Browsing through RFC 4380, I have found such spurious blank lines on
pages 23, 30, 33, 35, 41, 44, and 46.

RFC-Ed:
  A few weeks ago, I had promised to not complain repeatedly again
  about this issue.
  But the apparent frequency of the issue again has led me to suspect
  a procedural problem.  Please check.  Thanks!

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