Subject: Re: linting draft-ietf-msgtrk-protocol-00.txt

From: [email-masked]
Date: Thu, 27 Jul 2000 14:21:50 +0100

With regard to the security of the hashing - Steve Bellovin has written -
in draft-ietf-iab-secmech-01.txt (which has long since expired)

"5.2. HMAC

   HMAC [RFC2104] is the preferred shared-secret authentication
   technique.  If both sides know the same secret key, HMAC can be used
   to authenticate any arbitrary message.  This specifically includes
   random challenges, which means that HMAC is suitable for logins.

   The disadvantage, of course, is that the secret must be known in the
   clear by both parties.  In many situations, this is undesirable.

   When suitable, HMAC should be used in preference to older techniques,
   notably keyed hash functions.  Keyed hashes based on MD5 [RFC1321]
   are especially to be avoided, given the hints of weakness in MD5."

Are we sure that the proposal in draft-ietf-msgtrk-protocol-00.txt isn't
ignoring this advice ?

Cheers,
Paul
--
Paul Ford-Hutchinson : EMEA eCommerce application security :
[email-masked]
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5YR +44 (0)1926 462005

Lyndon Nerenberg <[email-masked]> on 26/07/2000 21:08:40

Please respond to Lyndon Nerenberg <[email-masked]>

To:   [email-masked]
cc:    (bcc: Paul V Ford-Hutchinson/UK/IBM)
Subject:  linting draft-ietf-msgtrk-protocol-00.txt

Here are a few things that popped out during my initial read of the
draft.

Section 3:

* line 2: s/message may issue the EHLO command/message MUST issue the
EHLO command/

Section 4.2.1

s/the Tracking ID is REQUIRED to be/the Tracking ID MUST be/

  "generational counter MUST be incremented by one."

contradicts the followon sentence. Suggest: "generational counter MUST
be incremented." and drop the following sentence (... small amount ...)
(or provide a rational for it?).

Section 4.2.2

  s/This secret value MAY be a per-message secret/This secret value
SHOULD
  be a per-message secret/

Is there a reason for MAY here instead of SHOULD?

Section 4.2.4

  "This value is then expressed as a series of
  32 hexadecimal digits, either lower- or upper-case, transmitted in
  internet byte order (low-endian ???? )"

This should read 'case independent'.

"internet byte order" reads as if it applies to the US-ASCII string.
This needs clarification that the ordering is of the underlying 16 byte
binary string.

Section 6.1

s/S: 25o <[email-masked]>/S: 250 <[email-masked]>/

Section 7

There *are* security issues with the hash calculations, and with the
requirements of section 4.2.2. We should at least draw attention to
the hazards of reusing the secret.

--lyndon

---

From: "Shiraz G. Bhanji" <[email-masked]>
Date: Thu, 27 Jul 2000 17:03:59 -0400

Paul,

I agree with your suggestion.
To reinforce your quote from Steve Bellovin about MD5,
I've been following the S/MIME WG and they have decided
to move away from MD5 and mandated SHA-1 in the latest
version of the S/MIME specs. Here's a quote from
RFC 2633 on S/MIME v3 specs:

"2.1 DigestAlgorithmIdentifier

   Sending and receiving agents MUST support SHA-1 [SHA1].  Receiving
   agents SHOULD support MD5 [MD5] for the purpose of providing backward
   compatibility with MD5-digested S/MIME v2 SignedData objects."

Since we are at the beginning of the development cycle, it would make
sense
for us to adopt the most current digest algos and not have to worry
about
backwards compatibility. Thanks.

Shiraz