[Rmt] AD review: draft-ietf-rmt-simple-auth-for-alc-norm, part I

"David Harrington" <ietfdbh@comcast.net> Fri, 19 November 2010 22:24 UTC

Return-Path: <ietfdbh@comcast.net>
X-Original-To: rmt@core3.amsl.com
Delivered-To: rmt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633CE3A68ED for <rmt@core3.amsl.com>; Fri, 19 Nov 2010 14:24:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Level:
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 i-z29XiAtZBN for <rmt@core3.amsl.com>; Fri, 19 Nov 2010 14:24:11 -0800 (PST)
Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id 8B27B3A67F3 for <rmt@ietf.org>; Fri, 19 Nov 2010 14:24:11 -0800 (PST)
Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta15.emeryville.ca.mail.comcast.net with comcast id Z9oR1f0030lTkoCAFAR2wS; Fri, 19 Nov 2010 22:25:02 +0000
Received: from 23FX1C1 ([67.189.235.106]) by omta04.emeryville.ca.mail.comcast.net with comcast id ZAQz1f0052JQnJT8QAQzDN; Fri, 19 Nov 2010 22:25:01 +0000
From: David Harrington <ietfdbh@comcast.net>
To: rmt@ietf.org, draft-ietf-rmt-simple-auth-for-alc-norm@tools.ietf.org
Date: Fri, 19 Nov 2010 17:24:55 -0500
Message-ID: <ACF30C3CDF5143EEA0A3C87DADF80B20@23FX1C1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
Thread-index: AcuIOJeW0nl3SjunTECaWLZc2w5k5w==
Subject: [Rmt] AD review: draft-ietf-rmt-simple-auth-for-alc-norm, part I
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmt>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2010 22:24:14 -0000

AD review, part I, of draft-ietf-rmt-simple-auth-for-alc-norm-03

Hi,

In the abstract:
"Because ... well suited to low data sessions."
"If this approach also ... medium data rate sessions."
"Because ... not group members."
", and is useful ... members."
I recommend this analysis and conclusion text be in the meat of the
document, not in the abstract. 

section 1
s/check check/check/

"Reliability ..." does this refer to alc, or norm, or both? If both,
it might be good to separate this from the preceding sentences. If not
both, then the paragraph should be restructured to be clear what text
refers to ALC and what refers to NORM.

I'm on the secdir and I have no idea what "true auth" means. If there
is a true auth, is there also a "false auth"? I recommend this be
reworded to use acceptable security terminology. You might find better
terminology in RFC4949.

"when seeking for higher security levels" might be better reworded.

the discussion of "group Message Authentication Codes" has no
definition of what this is, and no reference, just an assertion of
what it is well-suited to. It might be better to describe the
solutions and give references. The analysis and conclusions might be
better later in the document. 

I don't know what "Immediate auth" means.

You use the same 4-bit ASID for multiple schemes and then use an
out-of-band mechanism to associate the actual scheme to the ASID. Why
not use distinct ASIDs to identify the Authentication Scheme? I read
5776, 5.1 but this doesn't explain why this OOB approach is taken.
Please add some text to explain why this is done this way.

The security considerations (here and in 5776) do not discuss the
potential vulnerabilities of this OOB startup association to ASID.

in 1.1, the second paragraph has analysis "which is useful to mitigate
..." but this section is supposed to be about scope, not doing
analysis and drawing conclusions.

paragraphs 4 and 5 of section 1.1 are not about the scope of this
document.

section 1.2 is a about terminology, and belongs in the terminology
section (1.3)

Do we really need all these abbreviations? 
n_k is used 8 times in the document. 3 uses are in defining the term.
Three use both key length and n_k: "key length, n_k,". In the table,
it is parenthetical "key size (n_k)". In the one case where it used
separate from "key length" or "key size", you could have simply used
"key length".

K_pub and K-Priv are each used three times - once to define it and
twice in text. Just saying "using the private key" and "using the
public key" would have been fine. 

K-g is used 7 times - once to define it, twice it is used with "the
shared group key, K-g,", once it used as "the K-g group key". Twice it
is used as "compute the group MAC, using K_g". Using "the group key"
would have been just fine.

In section 2.1, the signtaurew field is mentioned. It would be good to
show the message format before discussing its fields.

The second paragraph of 2.1 (in fact, most of 2.1) doesn't seem to be
about "principles"; it seems to be about processing.

It strikes me that these sections would be better organized as 1)
format (which has the fields that are manipulated during processing),
2) parameters (which must be initialized before processing), and 3)
processing.

in 7.1, you discuss digital signatures. But what if digital signatures
are not used? i.e. group MAC mode?

in 7.2.1 
s/memoryless/stateless/
Can replay be used as a DoS attack, consuming resources?

in 7.2.2, It is RECOMMENDED - why not MUST? (especially the last)

in 7.2.3, "will be silently discarded" - if this is normative
behavior, please use MUST. If this will happen because it is specified
elsewhere, then please provide a reference (per RFCXXXX, the message
will be silently discarded."

in 7.2.3, "has no impact since this objetc is probably already marked
..." Does it have no impact even if it is NOT marked? What impact
would it have if it wrere not marked?

are "close session" and  "close object"  the only control packets?

in 7.2.3, last paragraph, it is RECOMMENDED that the shared group key
is changed across sessions. RECOMMENDED is equivalent to SHOULD; when
is it acceptable to not follow this RECOMMENDATION?

I plan to do a more detailed review of technical sections 2,3,4 and 5.


David Harrington
Director, IETF Transport Area
ietfdbh@comcast.net (preferred for ietf)
dbharrington@huaweisymantec.com
+1 603 828 1401 (cell)