Re: [Rmt] AD Review, updated for draft-ietf-rmt-simple-auth-for-alc-norm-04

[Vincent Roca <[e-mail]>]

David,

Please find below my answers to your comments. The I-D has also been
updated accordingly.


> AD Review, updated for draft-ietf-rmt-simple-auth-for-alc-norm-04
> 
> I think this document is much more easily readable now. thank you.
> 
> s/group group/group/

Done.


> in 5.3.1, in the discussion of side effects, "n_m=32" is surrounded by
> unusual characters.

Sorry, I've been confused with LaTeX formatting. Corrected.


> in figure 8, HEL changed from 34 to 35; is this deliberate?

That's correct. Adding the Anti-replay Sequence Number means the
option is longer by one 32-bit word (HEL is a length in words).


> Anti-replay in -03- seems to have had more detailed security
> considerations regarding the sequence number. The monotonically
> increasing sequence number permits guessing/estimating/predicting
> sequence numbers by an attacker. I expect the Security ADs will raise
> this point.
> The impact of replay seemed better described in the previous version.

No, let's fix this issue now.
What I've proposed is similar to what exists in ESP (RFC4303], section 2.2)
from which I've borrowed some text. A difference is the SN field
length (40 bits instead of 32), but it does not change the principles.
The fact the SN is easily guessed is not a problem. The anti-replay
feature requires that the integrity check of a packet includes the
SN field, and that this SN field change for each packet sent.
The full mechanism is described in section 2.3.2.

I've added a sentence to clarify that this SN, when present, MUST be
initialized before calculating the signature, so that it is part of
the integrity check. That's something that was implicit before (which
is clearly an error).

NEW TEXT (2.3.2):
   The SN value of the
   Authentication Header Extension MUST be initialized before the
   signature generation process, in order to enable a receiver to check
   the SN value during the integrity verification process.

I've also moved a sentence explaining why anti-replay MUST be used
from the introduction of section 5.3 to section 5.3.2 where it belongs.
I've added a pointer to section 5.3.2 in the introduction of section
7.2 to justify why it MUST be used in that case.

I hope these changes will be sufficient.


> "ALC MAY be" sensitive => "ALC might be" sensitive.

Done.

> in 7.3, the list of references seems odd. I don't think you need to
> reference the multiple parameters sections in this text.

Indeed. Removed.


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

It was discussed during IETF68 meeting where the group decided to use
an Scheme ID (ASID). The group also decided NOT to register the ASID in
a IANA registry. However the meeting minutes (and my memory) are not clear
on the motivations.
I think there was no strong reason to opt for this OOB approach rather
than the IANA registration and therefore I haven't added any text.

http://www.ietf.org/proceedings/68/slides/rmt-3/sld6.htm
http://www.ietf.org/proceedings/68/minutes/rmt.txt, 3- TESLA for ALC/NORM)


> I suspect somebody might complain that you have a REQUIRED relative to
> an out-of-scope OOB protocol. As per RFC3365 "Strong Security", MUST
> is for implementers; should is for deployers. The OOB mechanism seems
> to be a deployment decision. If it is really required, then the
> parameter signaling should be in-scope so you can REQUIRE specific
> behavior in compliant implementations. You can try to get this
> through, but it could be seriously problematic in IESG Review. I
> recommend describing how important protecting the ASID assignment is,
> without stating it as REQUIRED. (I could of course be wrong and this
> text might be fine).

Right. I've replaced the requirement by:
        "SHOULD be carried in a secure way".


> in 7.2.3,it is RECOMMENDED that the shared group key is changed across
> sessions. 
> when is it acceptable to not follow this RECOMMENDATION?

Good point. If the two groups are composed of the same members, the
shared key COULD be reused, otherwise there's no choice but changing
it. I have clarified this. Since this is a recommendation but not
a strong requirement to protect against replay across several sessions,
I have moved this sentence at the end of the paragraph.

I have also changed the first part of this paragraph, where I
"RECOMMEND to change the TSI". [RFC5651] (section 5.1.  "LCT Header Format")
is in fact very clear and says it MUST change. There's no choice! 


Thanks a lot for your review.
Cheers,

  Vincent