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

From: Brian Weis <[email-masked]>
Date: Thu, 2 Oct 2008 12:24:42 -0700

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 teFrom [email-masked]  Thu Oct  2 12:23:14 2008
From: Brian Weis <[email-masked]>
Date: Thu, 2 Oct 2008 12:24:42 -0700
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: [MSEC] Review of draft-ietf-msec-tesla-for-alc-norm-05.txt
Sender: [email-masked]

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

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.

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?

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?

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

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 TELSA bootstrapping and and reference section 2.2.

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.

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

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

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 TELSA processing, but If it is afterwards then it  
should also be noted that the sequence number check doesn't mitigate  
TESLA processing on a replayed message.

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 TELSA messages. Will that be done as part of  
ALC-specific and NORM-specific I-Ds?

Nits
====

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

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

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

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

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

_______________________________________________
MSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/msec

rms "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".

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.

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?

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?

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

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 TELSA bootstrapping and and reference section 2.2.

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.

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

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

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 TELSA processing, but If it is afterwards then it  
should also be noted that the sequence number check doesn't mitigate  
TESLA processing on a replayed message.

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 TELSA messages. Will that be done as part of  
ALC-specific and NORM-specific I-Ds?

Nits
====

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

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

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

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

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

_______________________________________________
MSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/msec

---

From: <[email-masked]>
Date: Fri, 17 Oct 2008 10:27:11 +0100

Dear Vincent, Aurelien and Faurite,
  My name is Lei Liang from University of surrey, UK. As my colleague
Dr. Haitham Cruickshank talked with Vincent in the last IETF meeting, we
are working on a new TESLA synchronization method while integrating with
FLUTE, which is built on ALC, in a UK EPSRC project called
Satellite-Based Secure Multicast employing Hybrid Reliability. We think
your ID is definitely very interesting and we used it as a very
important reference in our study. So you have our support here :).
  The new synchronization method we proposed is trying to eliminate the
bidirectional channel requested by the direct synchronization as stated
in the TESLA RFC because the ALC does not need it, especially in a
satellite network. It is trying to take use of the FDT function in the
FLUTE protocol to deliver the TESLA bootstrapping message and the
information needed for synchronization. This can be achieved as long as
the FDT is periodically broadcasted or mulicasted to a well-known
address. This synchronization information is not a strong overhead but
the interval index in which the source is when sending the bootstrapping
message. It can also solve the scalability problem on the source when
the multicast group is big. We published our initial study in ICC'2008
and are implementing and validating the method now. Please find the
enclosed pdf version of the paper that has the detailed description. 
  I hope it can provide some useful thought for your ID and your
comments are more than welcome.

Best regards,

Lei Liang

Dear Vincent, Aurelien and Faurite,
  My name is Lei Liang from University of surrey, UK. As my colleague
Dr. Haitham Cruickshank talked with Vincent in the last IETF meeting, we
are working on a new TESLA synchronization method while integrating with
FLUTE, which is built on ALC, in a UK EPSRC project called
Satellite-Based Secure Multicast employing Hybrid Reliability. We think
your ID is definitely very interesting and we used it as a very
important reference in our study. So you have our support here :).
  The new synchronization method we proposed is trying to eliminate the
bidirectional channel requested by the direct synchronization as stated
in the TESLA RFC because the ALC does not need it, especially in a
satellite network. ItfQl1JqJBfd
_______________________________________________
MSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/msec

---

From: Vincent Roca <[email-masked]>
Date: Fri, 24 Oct 2008 10:27:19 +0200

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:
> 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
> ================
>
> 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.

> correctly ... including once in the AbstraFrom [email-masked]  Fri Oct 24 01:26:05 2008
Date: Fri, 24 Oct 2008 10:27:19 +0200
From: Vincent Roca <[email-masked]>
To: [email-masked], "Brian Weis (bew)" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked], [email-masked]
Subject: Re: [MSEC] Review of draft-ietf-msec-tesla-for-alc-norm-05.txt
Sender: [email-masked]

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:
> 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
> ================
>
> 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.

> correctly ... including once in the Abstct. 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.

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

> 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 membe 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 wirs 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 ll 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.

> packets". Also, second bullet: "a digital signatures" should be "a

=> VR: done

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

=> VR: done

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

> packets". Also, second bullet: "a digital signatures" should be "a

=> VR: done

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

=> VR: done

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

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

---

From: Vincent Roca <[email-masked]>
Date: Fri, 24 Oct 2008 10:39:44 +0200

Dear Lei,

Thanks a lot for your interest in TESLA and support.

Concerning your proposal, we don't agree with your idea,
but maybe we can discuss this offline.

Best regards,

  Vincent

---

From: Vincent Roca <[email-masked]>
Date: Fri, 24 Oct 2008 10:39:44 +0200

Dear Lei,

Best regards,

  Vincent

---

From: <[email-masked]>
Date: Fri, 24 Oct 2008 10:08:30 +0100

Hi, Vincent,
  Thanks a lot for your comments. We are working on them and will let
you know the answers as soon as possible.

Regards,
Lei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vincent Roca
Sent: 24 October 2008 09:40
To: Liang L Mr (CCSR)
Cc: Cruickshank HS Dr (CCSR); [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [MSEC] Review of draft-ietf-msec-tesla-for-alc-norm-05.txt

Dear Lei,

Best regards,

  Vincent

---

From: <[email-masked]>
Date: Fri, 24 Oct 2008 10:08:30 +0100

Hi, Vincent,

Regards,
Lei

-----Original Message-----

Dear Lei,

Best regards,

  Vincent