First of all, I need to apologize for this very late answer...
quickly wraps...
TOI/SBN/ESI information (i.e. what I had in mind) does not enable
to detect replay attacks reliably.
signature verification. That's very bad!
times. Relying on the congestion control header fields (e.g., WEBRC
purpose) is not a universal solution.
header. We can also take advantage of the reserved 12 bits to
the wrapping to 0 risk. What do you think? This would be a very
clean solution to the problem.
Here is an example (with the combined scheme). Of course we
Please find below my answers to the other comments.
Thanks a lot for your careful and very useful review.
Regards,
Vincent
---
> AD review, part I, of draft-ietf-rmt-simple-auth-for-alc-norm-03
>
> 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.
Done. Indeed, it seems more appropriate to have it in the bulk of the document.
> section 1
> s/check check/check/
Done.
> "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.
In this sentence, reliability refers to ALC. This is now made explicit.
> 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.
You're right, the wording is inappropriate. The goal was to distinguish
group level security (where an insider attack, within the group, cannot
be identified) from per-sender security. We have clarified both the
text and the table.
> "when seeking for higher security levels" might be better reworded.
Removed. Since we provide an explicit example just after, there's no
ambiguity.
> 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've added a reference to the section where group MAC is defined.
> I don't know what "Immediate auth" means.
Right. I've changed this by "Non delayed authentication" in the
table and have added a sentence in the bullet to explain what
this 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 reason is historic.
I initially thought of having a fixed (i.e. IANA registered) mapping
between ASID values and the actual mechanisms. The WG preferred to
have a dynamic mapping, which requires to have this OOB communication.
However I don't remember all the details, but there's in particular
the restrictions associated to the 4-bit field size.
> The security considerations (here and in 5776) do not discuss the
> potential vulnerabilities of this OOB startup association to ASID.
Right. I've added a dedicated section in the "Security Considerations"
to REQUIRE this to be communicated in a secure way. What this means
depends of course on the nature of this OOB mechanism.
> 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.
You're right, at this moment this is a gratuitous affirmation.
I've removed this "which is useful to mitigate..." sentence.
It will be clarified later on.
> paragraphs 4 and 5 of section 1.1 are not about the scope of this
> document.
Removed.
> section 1.2 is a about terminology, and belongs in the terminology
> section (1.3)
Moved as suggested.
> 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".
I've removed n_k altogether and replaced it by its definition.
> 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.
Removed and replaced by their definition.
> 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.
Removed and replaced by their definition.
> 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.
Good idea. I've changed this section accordingly as well as that of
the other authentication schemes.
> in 7.1, you discuss digital signatures. But what if digital signatures
> are not used? i.e. group MAC mode?
Right. The paragraph has been reorganized to clarify this.
Additionally, I've extended the RECOMMENDATION to limit the number
of authentication checks per time unit under attack situations (or
presumed so) to all the authentication schemes.
> in 7.2.1
> s/memoryless/stateless/
Done.
> Can replay be used as a DoS attack, consuming resources?
Yes (see the beginning of this email). That's a very good point!
> in 7.2.2, It is RECOMMENDED - why not MUST? (especially the last)
This section will be completely re-written if we add a dedicated
anti-replay sequence number.
> 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."
This section will be completely re-written if we add a dedicated
anti-replay sequence number.
> 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?
This section will be completely re-written if we add a dedicated
anti-replay sequence number.
> are "close session" and "close object" the only control packets?
This section will be completely re-written if we add a dedicated
anti-replay sequence number.
> 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?
This paragraph (ALC) and that of NORM will remain in any case, so
it's worth clarifying this point.
My answer: when we don't care about security at all.
If security is a concern, the MUST is preferable. That being said,
I'm not sure the NORM/ALC/LCT RFCs REQUIRE that different sessions
use different {"source_id"; "instance_id"} or {sender's IP address;
Transport Session Identifier (TSI)} tuples. I need to check...
> I plan to do a more detailed review of technical sections 2,3,4 and 5.
>
>
> David Harrington
> Director, IETF Transport Area
>
ietfdbh <at> comcast.net (preferred for ietf)
> dbharrington <at> huaweisymantec.com
> +1 603 828 1401 (cell)
RSS Feed