Re: [Rmt] AD review: draft-ietf-rmt-simple-auth-for-alc-norm, part I
Vincent Roca <vincent.roca@inrialpes.fr> Fri, 08 July 2011 10:29 UTC
Return-Path: <vincent.roca@inrialpes.fr>
X-Original-To: rmt@ietfa.amsl.com
Delivered-To: rmt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354B321F8682 for <rmt@ietfa.amsl.com>; Fri, 8 Jul 2011 03:29:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.806
X-Spam-Level:
X-Spam-Status: No, score=-9.806 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKN7p+hbidbS for <rmt@ietfa.amsl.com>; Fri, 8 Jul 2011 03:29:23 -0700 (PDT)
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 29B6A21F89BD for <rmt@ietf.org>; Fri, 8 Jul 2011 03:29:21 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.65,498,1304287200"; d="scan'208,217"; a="102753097"
Received: from geve.inrialpes.fr ([194.199.24.116]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 08 Jul 2011 12:29:20 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-2--1046205547"
From: Vincent Roca <vincent.roca@inrialpes.fr>
In-Reply-To: <B0E66296-BB4B-47F1-8CE9-12AD1FE531C6@inrialpes.fr>
Date: Fri, 08 Jul 2011 12:29:19 +0200
Message-Id: <70741E4D-908F-4A89-AC24-2F28E28E310D@inrialpes.fr>
References: <ACF30C3CDF5143EEA0A3C87DADF80B20@23FX1C1> <B0E66296-BB4B-47F1-8CE9-12AD1FE531C6@inrialpes.fr>
To: David Harrington <ietfdbh@comcast.net>, rmt@ietf.org
X-Mailer: Apple Mail (2.1084)
Cc: draft-ietf-rmt-simple-auth-for-alc-norm@tools.ietf.org
Subject: Re: [Rmt] AD review: draft-ietf-rmt-simple-auth-for-alc-norm, part I
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 08 Jul 2011 10:29:25 -0000
David, all, I've just updated the simple-auth-for-alc-norm I-D in order to implement the anti-replay protection feature, as I have suggested end of May. Summary: - anti-replay MUST be used in case of combined signature/group MAC, otherwise replaying a valid packet is an easy way to bypass the "light" group MAC filtering. - anti-replay has been added to the other authentication schemes, as an option. Their use is however RECOMMENDED. - using NORM "sequence number" feature to provide anti-replay is no longer considered as suitable, given the small field size (16 bits). It is therefore RECOMMENDED to use the anti-replay feature of this I-D. - the ALC protocol is more robust in front of replay attacks, there's just a small risk when using certain EXT_TIME LCT header extensions. This is now clarified. All the comments have been considered, as explained below. Regards, Vincent On May 27, 2011, 13:58, Vincent Roca wrote: > Hello David, > > First of all, I need to apologize for this very late answer... > > A major issue (that was completely overlooked) is the replay > protection limits with both NORM and ALC protocols: > - in case of NORM, because NORM's seqnum is a 16-bit field which > quickly wraps... > - in case of ALC because there's no seqnum and using the > TOI/SBN/ESI information (i.e. what I had in mind) does not enable > to detect replay attacks reliably. > Now the problem is that a replayed packet with a combined > digital signature/group MAC will always pass the group MAC > check, and therefore each replayed packet will require a > signature verification. That's very bad! > > I can't find any effective solution: checking the TOI/SBN/ESI > first, then the group MAC, then the signature is not sufficient > since a sender may send the same encoding symbol several > times. Relying on the congestion control header fields (e.g., WEBRC > has the {channel #|pkt seq #} fields that may be used to that > purpose) is not a universal solution. > > My proposal: add a dedicated "seq" field within the EXT_AUTH > header. We can also take advantage of the reserved 12 bits to > increase this field size to 32+12=44 bits and therefore reduce > 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 > can do the same with the other schemes: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | HET (=1) | HEL | ASID | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > | anti-replay sequence number (seq) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ ~ > | Signature | > + +-+-+-+-+-+-+-+-+ > | | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Group MAC | > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Please find below my answers to the other comments. > I've prepared an updated version of the I-D: > > http://planete.inrialpes.fr/people/roca/doc/draft-ietf-rmt-simple-auth-for-alc-norm-04a.html > http://planete.inrialpes.fr/people/roca/doc/draft-ietf-rmt-simple-auth-for-alc-norm-04a.txt > > 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@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell)
- [Rmt] AD review: draft-ietf-rmt-simple-auth-for-a… David Harrington
- Re: [Rmt] AD review: draft-ietf-rmt-simple-auth-f… Vincent Roca
- Re: [Rmt] AD review: draft-ietf-rmt-simple-auth-f… Vincent Roca