Re: [Rmt] [MSEC] Review of draft-ietf-msec-tesla-for-alc-norm-05.txt

Dear Brian and Ramu,

Thanks a lot for your comments. Please find below our answers
as well as a record of four additional changes done to the I-D
(at the end of this email). Sorry if this is a little bit long.
I'll do a summary during next IETF meeting.

The new I-D is *not* completely finished since we still need to
clarify the IANA issue and update the examples of section 5.2
to reflect the fact that SHA-256 is the new default.

Once again thanks a lot for the time spent reading this document.

Best regards,

  Vincent, Aurelien and Sebastien

NB: I'm also adding the RMT list to the CC.

Brian Weis wrote:
> Hi Vincent, Aurelien, and Sebastien,
>
> I have reviewed this draft as part of the MSEC WG last call (as a
> working group member), and have the following comments. If any of them
> are unclear I would be happy to discuss them.
>
> Thanks,
> Brian
>
> General comments
> ================
>
> 1. The terms "weak group authentication tag" and "weak group MAC" may
> sound a bit pejorative to readers not familiar with group security.
> Protecting against attackers that are not group members is an important
> property. I recommend removing the term "weak".

=> VR: You're right, we removed "weak" and change the "W" flag to "G"
   for coherency purposes in the bootstrap message.

> 2. The term "out of the scope" is repeated 11 times, if I counted
> correctly ... including once in the Abstract. I'm not doubting that
> those areas ARE out of scope for the document, but reading that phrase
> so often makes the reader wonder if the I-D leaves too MUCH out of scope
> (and I'd expect this question to arise as the I-D progresses to a wider
> IETF review). It might be a good idea to add a scope section at the
> beginning of the document to declare once what is and is not in scope,
> and then remove as many of those individual statements as possible.

=> VR: We have added a "1.1 Scope" section where all the topics
   that are out of scope are gathered. That's a very good idea.
   We removed the "out of the scope" that are only duplicates
   (e.g., in section 5.1), but we left the other ones, even if it
   has already been clarified in section "1.1 Scope".

   However we think our assumptions of what is inside/outside
   of this I-D are reasonable.

> 3. Whether or not NTP is required to support TESLA isn't clear. Some
> places seems to indicate it is required (e.g., the bullets in section
> 1.2.2), however section 2.3.2 gives a range of options for time
> synchronization. The bits-on-the-wired description in section 3.4.1
> seems to require an NTP timestamp, although it isn't clear that the
> bootstrap information message requires the use of direct time
> synchronization.  Could you clarify the conditions under which NTP is a
> requirement?

=> VR: secure time sync is a MUST. How to do that is left to the
   developer. NTP is one option among others. More precisely:
   - Section 1.2.2: corrected by "(in NTP timestamp format)",
     irrespective of whether NTP is used or not. The NTP timestamp
     format is also detailed and a reference given to RFC1305;
   - 2.3.2: wording is correct => left untouched;
   - Sections 3.4.1, 3.4.2, 4.2.2.1: corrected by "in NTP timestamp format";

> 4. In some text "NTP" is specified, and sometimes "(S)NTP" is specified.
> Is it possible to be consistent, or are times when NTP must be used
> rather than SNTP?

=> VR: by (S)NTP we mean either NTP or SNTP. We removed all the (S)NTP
   acronyms and replaced them with NTP/SNTP.

> Specific comments
> =================
>
> Section 1. The last paragraph says "This specification does not consider
> the packets that may be sent by receivers, for instance NORM's feedback
> packets.  Adding authentication/integrity to the packets sent by
> receivers is out of the scope of this document." This makes the reader
> wonder if there's enough value to applying TESLA to NORM when it can
> only protect packets in one direction. Can you add a short rationale
> explaining why it is OK to declare TESLA reverse packets out of scope?
> (Note that section 2.1 states "NORM requires a bidirectional transport
> channel", so it seems clear that any rationale security policy will
> require securing the back channel  by in parallel.)

=> VR: in fact, there is a missing background information here. I am
   working in parallel on a "Simple Authentication Schemes for the ALC
   and NORM Protocols" (RMT WG item document), where we specify the use
   of digital signatures and group MAC as alternative authentication
   services. In practice, TESLA could be used for the high-rate downstream
   flow, and a mixture of Digital Sig/Group MAC for the low-rate upstream
   flow with NORM (there is no such flow with ALC anyway).
   The ASID (auth. scheme ID) field in the EXT_AUTH header extension
   is meant to enable the parallel use of several authentication schemes.

   The Introduction, section 1.2 "Scope", clarifies this point as follows:

  "This specification does
   not consider the packets that may be sent by receivers, for instance
   NORM's feedback packets.  However, since this is usually a low-rate
   flow (unlike the downstream flow), using computing intensive techniques
   like digital signatures is often acceptable.  The Section 5 explains how to
   use several authentication schemes in a given session, which can be
   used to that purpose."

> Section 1.2.1. The next-to-last bullet says "The mechanism by which this
> group key is shared by the group members is out of the scope of this
> document". The distribution of the group key could be related to the
> bootstrapping discussion in section 2.2. Instead of saying it is out of
> scope, perhaps you could say that it SHOULD be distributed during TESLA
> bootstrapping and and reference section 2.2.

=> VR: of course, the group key K_g must be distributed during the
   bootstrapping step (but not as part of the bootstrap message, as
   explained in section 2.2.2). I've added a reference to section 2.2
   but the actual mechanism remains "out of the scope.
   There is also a note in the new "1.2 Scope" section.

> Section 2.3.2. This section mandates the use of SHA-1, which is a side
> effect of modeling the signature semantics after RFC 4359. However,
> since the time that RFC was published there has been a number of attacks
> on SHA-1, and the current guidance is that IETF drafts should specify a
> SHA-256 hash for signatures.  You should justify why a signature over a
> SHA-1 hash (as opposed to a SHA-256 hash) is acceptable, or else change
> the specification to be a SHA-256 hash.

=> VR:
   We have two uses of SHA-*: for HMAC and for digital signatures.

 - I thought that HMAC-SHA1 was still acceptable. My reference was
   D. McGrew's presentation during the plenary of Nov. 2005:
   http://www.ietf.org/proceedings/05nov/slides/plenaryt-2.pdf
   But it is already a 3 year old document and 2011 is approaching...
   So let's change for 256.

 - Concerning digital signatures, my reference is your RFC 4359, saying
   that "SHA-1 MUST be used as the signature hash algorithm used by the
   RSA digital signature algorithm". Since there is a "MUST", I concluded
   I had no choice. If I understand correctly, this RFC should be ignored
   (!) and SHA-256 be used in place of SHA-1 in RSASSA-* signatures.
   So I've added several lines in the "7. IANA considerations" section
   for SHA-256 (new default), SHA-224, SHA-384 and SHA-512. Is that correct?
   I must confess I'm totally ignorant...

   However I haven't changed the examples yet (not enough time)... I'll
   do that later on.

> Section 4.2. In step 2, it isn't clear how much processing the receiver
> has it receives a compact authentication header and has to "guess"  the
> value of i. What happens if the receiver "guesses" the value of i wrong?
> Can it tell without progressing to the next step (group MAC check)?

=> VR: that's a key point, you're right.
   I have added a whole section, 4.2.1, that details this important point.
   In summary:
   - of course, the probability that it happens is higher if only i_LSB
     is used, not the extra i_NSB two bytes;
   - a wrong "i" value can be caused by a delayed packet. An analysis shows
     that the probability it happens is rather low;
   - of course, an attacker can corrupt the "i_LSB" field, therefore leading
     to a wrong "i" guess. However the problem is identical if an attacker
     corrupts directly the full "i" field;
   - in all cases, the wrong "i" will be caught either in step 2, step 4a
     or 4b, or step 7. It does not compromise TESLA robustness;
   The details are in the new section.

> Section 6.1. I suggest rewording the second paragraph to something like
> this: "In order to mitigate these attacks, it is RECOMMENDED to use the
> Weak Group MAC scheme (Section 3.3.3). No mitigation is possible if a
> group member acts as an attacker."

=> VR: done

> Section 6.2.2. This section should say whether or not the NORM sequence
> number check happens before the TESLA processing. I suspect it happens
> before TESLA processing, but If it is afterward then it should also be
> noted that the sequence number check doesn't mitigate TESLA processing
> on a replayed message.

=> VR: good point. Both options seem feasible, with the limit that you
   mention if it happens after TESLA processing. Good practice is to
   check before, but if ever this is not the case, it does not compromise
   security since TESLA processing is robust to replay attacks
   (section 6.2.1). So we say "SHOULD be done before".

> Section 7. IANA will need to know whether they need to create a new
> registry, or whether these are added to an existing. Also, I'm surprised
> that the document does not describe any ALC and NORM registry entries
> for the TESLA messages. Will that be done as part of ALC-specific and
> NORM-specific I-Ds?

=> VR: you're perfectly right, and this is our fault!
   I will do a proposal, ask to both RMT/MSEC lists, in order to get a
   consensus.

> Nits
> ====
>
> Sections 3.4.5 and 3.4.6 seem to have quote marks that are not 7-bit ASCII.

=> VR: the `` and '' in the title are here to avoid confusion with
   regular " " quote marks, already used by the XML <section title="...">
   element. Maybe there's an escape parameter? Didn't try.

> Section 3.3. First bullet: "of a data packets" should be "of data
> packets". Also, second bullet: "a digital signatures" should be "a
> digital signature".

=> VR: done

> Section 3.3.3. First sentence: "not group member" should be "not group
> members".

=> VR: done

> Section 6.2.1. Second bullet: "that is not member" should be "that is
> not a member". Also, "which requires to" should be "which requires it to".

=> VR: done

=================================
Ramu Panayappan wrote:
> Hi,
>
> Brian had asked the security group at CMU, to have a quick look at the
> draft to check if there are any issues with the way TESLA is being used.
>
> At the outset, there are no apparent issues with the way it has been
> used. However, I have a few comments (see below) in form of
> questions/suggestions to ascertain that my conclusions are correct.  A
> couple of nits are also noted. Feel free to ignore those.
>
> Thanks
> Ramu
>
>
> --------------
>
>
> 2.3.2 (Nit)
> Use of GPS as secure time source is a issue almost always as GPS timings
> signals can be spoofed easily. Methods like "dead reckoning" may be used
> to circumvent spurious GPS signals to certain extent. It may be
> worthwhile to add a "caution" of not using this method for synchronization.

=> VR: you're right, spoofing attacks exist for GPS systems. We now
   mention them explicitly.

> 3.3.1 (Nit)
> What is the F' function? (probably some reference to later section might
> help)

=> VR: F' is fully defined in section 3.1.2.1. A reference to this
   section is added in the "Notations and Definitions" section.
   I've also clarified what f_k means W.R.T. f and k in section 3.1.2.1.

> 3.3.2 (Assumption)
>
> Bootstrap Message signing:  Assumes that the receiver obtains the
> verifying key corresponding to the signing key K of the sender by some
> means. May be add this as a pre-requisite for receiver side in Section 4.

=> VR: you're perfectly right. As suggested by Brian, we have added a
   new section "Scope", in the introduction, where all such assumptions
   are gathered and discussed.

> 3.3.3 (Question & suggestion)
>
> What is the reasoning behind including  the digital signature (e.g., of
> a bootstrap message) and the MAC fields (e.g., of an authentication tag)
> while computing the Weak group MAC Tag. Since this is just a preliminary
> check the group MAC tag can be computed devoid of it and thus helping
> the sender to parallize the computations of group MAC tag and computing
> authentication tags on the packet.

=> VR: you're right, we had in mind a sequential (rather than parallel)
   processing of incoming packets:
	first check the Group MAC, then check the signature.
   The motivation is that a corrupted signature will be identified without
   having to go through the costly signature verification process.
   In other words, it helps mitigating an external attack.

> (As a side note given that groups change dynamically and the group keys
> are rekeyed periodically it might be a implementation hurdle to always
> tag the correct group MAC tag. This might require accepting group MAC
> based on older group keys too. May be it is worth cautioning this and
> cite it as "out of scope").

=> VR: In the new "Scope" section, it is explicitly mentioned that group
   keys might be re-keyed periodically. However, I don't understand why
   older group keys would have to be accepted, unless we assume that the
   re-keying mechanism is not sufficiently real-time and reliable.
   Accepting older group keys looks tricky to me. I prefer that some
   receivers loose some packets during the transition.

> 6. Security Considerations: (Suggestion)
>
> In addition to the correct calculation of D-t the choice of time
> intervals is critical for TESLA to function correctly. It should be
> noted that (d * time interval) should b greater than the propagation
> delay to reach from sender to receiver. (Not sure whether this is
> already taken care of by the nuances of the existing protocols).

=> VR: you're perfectly right. We say in section 3.1.3 that the
   right place to find such considerations is RFC4082. We chose not
   to repeat the recommendations here.

> 6.1 DoS (Suggestion)
>
> In addition to those mentioned,
> DoS is possible by bombarding with spurious bootstrap packets or
> bombarding with synchronization packets. Recommendations for these may
> also be helpful.

=> VR: perfectly right (and this is why we added Group MAC).
   We now mention it explicitly in section 6.1.

> 6.2.2 Impact of replay attacks on NORM (Question)
>
> Does the sequence number check happen before the TESLA processing?

=> VR: see answer to Brian's question above. It SHOULD happen before.

=======================================

ADDITIONAL MODIFICATIONS:

* corrected error Fig. 16: this is a compact (rather than standard) auth. tag,
  as suggested by the message type (5).

* section 4.2 "Authentication of received packets"
  We have corrected step 4a and 4b. It does not change fundamentally the
  situation, it's just more natural. Basically, the point is whether the
  receiver stores the missing keys between K_v and K_{i-d} (with v < i-d),
  both keys having been legitimated, or not.
  Before: don't store them
  Now: store them all, since anyway they will have to be processed during
  the K_{i-d} validation process.

* Section 4.2.2 "Discarding unnecessary packets earlier"
  We have added this section. It's only an optimization, since some
  packets can be safely discarded, before TESLA authentication.
  E.g., this is the case with pure data packets for an object that
  the user does not want.

* Section 3.3.3 "Format of a Standard Auth Tag"
  We clarified that MAC(K'_i, M) is truncated. It was only mentioned in
  Section 1.2.1 and implicitly in the IANA section, which was misleading.

_______________________________________________
Rmt mailing list
Rmt@ietf.org
https://www.ietf.org/mailman/listinfo/rmt