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

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
[email protected] (preferred for ietf)
[email protected]
+1 603 828 1401 (cell)