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

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 protected]
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5YR +44 (0)1926 462005


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

Please respond to Lyndon Nerenberg <[email protected]>

To:   [email protected]
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 protected]>/S: 250 <[email protected]>/

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