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

[Brian Weis <[e-mail]>]

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 [e-mail]  Thu Oct  2 12:23:14 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 49DEA3A6A05;
	Thu,  2 Oct 2008 12:23:14 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 84BF63A6A05
	for <[e-mail]>; Thu,  2 Oct 2008 12:23:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id oGfxgtVGu9kY for <[e-mail]>;
	Thu,  2 Oct 2008 12:23:12 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117])
	by core3.amsl.com (Postfix) with ESMTP id 57B623A6872
	for <[e-mail]>; Thu,  2 Oct 2008 12:23:12 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,352,1220227200"; d="scan'208";a="167569079"
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-6.cisco.com with ESMTP; 02 Oct 2008 19:22:57 +0000
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m92JMvCX026520; 
	Thu, 2 Oct 2008 12:22:57 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m92JMvEH011522;
	Thu, 2 Oct 2008 19:22:57 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 2 Oct 2008 12:22:57 -0700
Received: from [128.107.163.243] ([128.107.163.243]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 2 Oct 2008 12:22:57 -0700
Mime-Version: 1.0 (Apple Message framework v753.1)
Message-Id: <[e-mail]>
From: Brian Weis <[e-mail]>
Date: Thu, 2 Oct 2008 12:24:42 -0700
To: [e-mail], [e-mail], [e-mail]
X-Mailer: Apple Mail (2.753.1)
X-OriginalArrivalTime: 02 Oct 2008 19:22:57.0373 (UTC)
	FILETIME=[469E28D0:01C924C4]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5302; t=1222975377;
	x=1223839377; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=[e-mail];
	z=From:=20Brian=20Weis=20<[e-mail]>
	|Subject:=20Review=20of=20draft-ietf-msec-tesla-for-alc-nor
	m-05.txt |Sender:=20;
	bh=ynnC+cI53e33MfJOf8dm8UGhKXFR1h1j0mzxsgrXGe4=;
	b=ZrsDoz7ypRSqgpVmSGNEIr4lVCkls1U8t6Pe61t3zKCziJ7MCJzMSlaFlp
	/osmsqqYtlwgST+7sn5vDXa7+ANlgpCWMN/YEVuyixCMwVO5FIfhsxTmPXHW
	Wy1GzL3LeH;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
Cc: [e-mail]
Subject: [MSEC] Review of draft-ietf-msec-tesla-for-alc-norm-05.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast Security List <msec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/msec>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/msec>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/msec>,
	<mailto:[e-mail]?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: [e-mail]
Errors-To: [e-mail]

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: [phone]
Email: [e-mail]

_______________________________________________
MSEC mailing list
[e-mail]
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: [phone]
Email: [e-mail]

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