From Brian.Adamson@nrl.navy.mil Tue Jul 5 12:41:04 2011 Return-Path: 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 CC95C21F85F6 for ; Tue, 5 Jul 2011 12:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 8CN-xyXIiYU6 for ; Tue, 5 Jul 2011 12:41:02 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAB721F85F5 for ; Tue, 5 Jul 2011 12:41:01 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p65Jf0t7011013; Tue, 5 Jul 2011 15:41:00 -0400 Received: from macsimus.itd.nrl.navy.mil ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011070515405918203 ; Tue, 05 Jul 2011 15:40:59 -0400 From: Brian Adamson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 5 Jul 2011 15:39:50 -0400 Message-Id: <0B3B27EE-443B-4EAD-8D15-74BB2713BEFC@nrl.navy.mil> To: rmt@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Brian Adamson Subject: [Rmt] IETF 81 RMT - Call for Agenda Items X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 19:41:04 -0000 Please submit any RMT Working Group agenda items by Mon, 11 July 2011. The RMT Meeting is scheduled fo Friday, 29 July 2011 at 1300-1400. best regards, Brian Adamson adamson@itd.nrl.navy.mil From ietfdbh@comcast.net Tue Jul 5 14:42:09 2011 Return-Path: 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 14A9221F8821 for ; Tue, 5 Jul 2011 14:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.558 X-Spam-Level: X-Spam-Status: No, score=-101.558 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, SARE_OBFU_PART_ING=1.666, USER_IN_WHITELIST=-100] 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 7dhobiZmN8GT for ; Tue, 5 Jul 2011 14:42:08 -0700 (PDT) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC1021F881F for ; Tue, 5 Jul 2011 14:42:08 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 4KUx1h0031smiN4A4Mi6aw; Tue, 05 Jul 2011 21:42:06 +0000 Received: from davidPC ([67.189.235.106]) by omta20.emeryville.ca.mail.comcast.net with comcast id 4Mjc1h00W2JQnJT8gMjcTh; Tue, 05 Jul 2011 21:43:38 +0000 From: "David Harrington" To: , , Date: Tue, 5 Jul 2011 17:41:57 -0400 Message-ID: <37F236FD0AF246E39DE213A467A39D82@davidPC> 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.1.7601.17609 Thread-index: Acw7XF0vHrb1/P0WQhCFHwty19rkww== Subject: [Rmt] AD followup for draft-ietf-rmt-flute-revised-12 X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 21:42:09 -0000 draft-ietf-rmt-flute-revised-12 AD Followup *** WG take note *** I am suggesting tightening some RFC2119 language; if you object to specific changes please speak up. There are a few issues I found in my followup review, mostly about RFC2119-like language. I also had some questions that might just be my misunderstandings. If you can get them addressed before the cutoff on 7-11, we might be able to advance the draft in the process before ietf81. 1) in Introduction, it says version "may not be" to avoid confusion, please use might not. better yet, state whether it is or is not backwards compatible. I can submit this as is, but I expect it will get pushback from other IESG members for being unclear. If there is a lack of WG consensus on this point, then document that in the shepherd writeup. 2) in 3.1, s/MAY NOT/might not/ 3) "The TOI value of '0' MUST be reserved for delivery of FDT Instances. The use of other TOI values for FDT Instances is outside the scope of this specification." Shouldn't this specification at least define the range and type of values; are these integer values? If it is not in scope for THIS specification, what specification is it in scope for? 4) This document defines new extensions to LCT and ALC; should this be declared as Updates LCT and ALC? 5) " In any case, both a sender and a receiver can determine to which (136 year) epoch the FDT Instance expiration time value pertains to by choosing the epoch for which the expiration time is closest in time to the current time." Can you provide an example? I find this unclear. I am especially unclear about edge cases, such as for when the expiration time and current time are in different epochs. 6) "The space of FDT Instance IDs is limited"; where is this space limit specified? 7) " * The receiver SHOULD NOT use a received FDT Instance to interpret" - SHOULD implies there are valid reasons nto to comply with this rule. What are the valid exceptions? or should this be a MUST NOT? 8) "should achieve" and "should be delivered"; are these RFC2119 shoulds? if so please capitalize; if not please change the wording. 9) " Senders SHOULD NOT re-use an FDT Instance ID value that is already in" why not MUST NOT? "value that is currently used by a non expired FDT Instance SHOULD be considered as an error case." why not MUST? 10) in 3.4, the field SHOULD be ignored. why not MUST? 11) 3.1 says compliant implementations MUST set the flute version to 2; 3.4.1 says something similar. section 6 says the information is optional. these seem contradictory. Comment: 1) 1.1.4 missing period at end of sentence. 2) references are out of date, because I took so long to followup. idnits tools can help identify the needed updates. 3) LCT needs expansion on first use 4) in 3.2, is unmapped TOI handlng described elsewhere, such as in LCT or ALC? I think the IESG could push back on why isn't this an error with a defined response by the receiver. It would help if the text was explicit about the handling, or explained why the situation could occur in compliant implementations. 5) s/may be lost/might be lost/ David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From internet-drafts@ietf.org Fri Jul 8 03:15:09 2011 Return-Path: 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 E58CD21F89D1; Fri, 8 Jul 2011 03:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 661GHn+54IjM; Fri, 8 Jul 2011 03:15:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0C121F89BF; Fri, 8 Jul 2011 03:15:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110708101509.19444.50880.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 03:15:09 -0700 Cc: rmt@ietf.org Subject: [Rmt] I-D Action: draft-ietf-rmt-simple-auth-for-alc-norm-04.txt X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 10:15:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Reliable Multicast Transport Working = Group of the IETF. Title : Simple Authentication Schemes for the ALC and NORM Proto= cols Author(s) : Vincent Roca Filename : draft-ietf-rmt-simple-auth-for-alc-norm-04.txt Pages : 32 Date : 2011-07-08 This document introduces four schemes that provide per-packet authentication, integrity and anti-replay services in the context of the ALC and NORM protocols. The first scheme is based on digital signatures. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). The third scheme relies on a group Message Authentication Code (MAC). Finally, the fourth scheme merges the digital signature and group group schemes. These schemes have different target use cases and they do not all provide the same service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-simple-auth-for-alc-norm= -04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rmt-simple-auth-for-alc-norm-= 04.txt From vincent.roca@inrialpes.fr Fri Jul 8 03:29:25 2011 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: Date: Fri, 8 Jul 2011 12:29:19 +0200 Message-Id: <70741E4D-908F-4A89-AC24-2F28E28E310D@inrialpes.fr> References: To: David Harrington , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 10:29:25 -0000 --Apple-Mail-2--1046205547 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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=20 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, >=20 > First of all, I need to apologize for this very late answer... >=20 > A major issue (that was completely overlooked) is the replay > protection limits with both NORM and ALC protocols:=20 > - 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! >=20 > 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. >=20 > 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=3D44 bits and therefore reduce > the wrapping to 0 risk. What do you think? This would be a very > clean solution to the problem. >=20 > Here is an example (with the combined scheme). Of course we > can do the same with the other schemes: >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | HET (=3D1) | HEL | ASID | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > | anti-replay sequence number (seq) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ ~ > | Signature | > + +-+-+-+-+-+-+-+-+ > | | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Group MAC | > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Please find below my answers to the other comments. > I've prepared an updated version of the I-D: >=20 > = 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 >=20 > Thanks a lot for your careful and very useful review. > Regards, >=20 > Vincent >=20 > --- >=20 > > AD review, part I, of draft-ietf-rmt-simple-auth-for-alc-norm-03 > >=20 > > 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.=20 >=20 > Done. Indeed, it seems more appropriate to have it in the bulk of the = document. >=20 >=20 > > section 1 > > s/check check/check/ >=20 > Done. >=20 >=20 > > "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. >=20 > In this sentence, reliability refers to ALC. This is now made = explicit. >=20 >=20 > > 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. >=20 > 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. >=20 >=20 > > "when seeking for higher security levels" might be better reworded. >=20 > Removed. Since we provide an explicit example just after, there's no > ambiguity. >=20 >=20 > > 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.=20 >=20 > I've added a reference to the section where group MAC is defined. >=20 >=20 > > I don't know what "Immediate auth" means. >=20 > 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. >=20 >=20 > > 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. >=20 > 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. >=20 >=20 > > The security considerations (here and in 5776) do not discuss the > > potential vulnerabilities of this OOB startup association to ASID. >=20 > 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. >=20 >=20 > > 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. >=20 > 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. >=20 >=20 > > paragraphs 4 and 5 of section 1.1 are not about the scope of this > > document. >=20 > Removed. >=20 >=20 > > section 1.2 is a about terminology, and belongs in the terminology > > section (1.3) >=20 > Moved as suggested. >=20 >=20 > > Do we really need all these abbreviations?=20 > > 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". >=20 > I've removed n_k altogether and replaced it by its definition. >=20 >=20 > > 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.=20 >=20 > Removed and replaced by their definition. >=20 >=20 > > 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. >=20 > Removed and replaced by their definition.=20 >=20 >=20 > > In section 2.1, the signtaurew field is mentioned. It would be good = to > > show the message format before discussing its fields. > >=20 > > 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. > >=20 > > 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. >=20 > Good idea. I've changed this section accordingly as well as that of > the other authentication schemes. >=20 > =20 > > in 7.1, you discuss digital signatures. But what if digital = signatures > > are not used? i.e. group MAC mode? >=20 > 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. >=20 >=20 > > in 7.2.1=20 > > s/memoryless/stateless/ >=20 > Done. >=20 >=20 > > Can replay be used as a DoS attack, consuming resources? >=20 > Yes (see the beginning of this email). That's a very good point! >=20 >=20 > > in 7.2.2, It is RECOMMENDED - why not MUST? (especially the last) >=20 > This section will be completely re-written if we add a dedicated > anti-replay sequence number. >=20 >=20 > > 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." >=20 > This section will be completely re-written if we add a dedicated > anti-replay sequence number. >=20 >=20 > > 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? >=20 > This section will be completely re-written if we add a dedicated > anti-replay sequence number. >=20 > > are "close session" and "close object" the only control packets? >=20 > This section will be completely re-written if we add a dedicated > anti-replay sequence number. >=20 >=20 > > 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? >=20 > This paragraph (ALC) and that of NORM will remain in any case, so > it's worth clarifying this point. >=20 > 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... >=20 >=20 > > I plan to do a more detailed review of technical sections 2,3,4 and = 5. > >=20 > >=20 > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) --Apple-Mail-2--1046205547 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
  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=3D44 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 (=3D1)    |      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:


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 (preferre= d for ietf)
> dbharrington@huaweisymante= c.com
> +1 603 828 1401 = (cell)

= --Apple-Mail-2--1046205547-- From brian.adamson@nrl.navy.mil Mon Jul 18 09:52:20 2011 Return-Path: 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 E115721F8A4B for ; Mon, 18 Jul 2011 09:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 tMbZy4jPoWzO for ; Mon, 18 Jul 2011 09:52:20 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietfa.amsl.com (Postfix) with ESMTP id 2106F21F893E for ; Mon, 18 Jul 2011 09:52:19 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p6IGqHX8031831; Mon, 18 Jul 2011 12:52:17 -0400 Received: from macsimus.itd.nrl.navy.mil ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011071812521703749 ; Mon, 18 Jul 2011 12:52:17 -0400 From: brian.adamson@nrl.navy.mil Content-Type: multipart/alternative; boundary=Apple-Mail-35--159299133 Date: Mon, 18 Jul 2011 12:51:06 -0400 Message-Id: To: rmt@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Rmt] IETF 81 RMT WG Draft Agenda posted X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 16:52:21 -0000 --Apple-Mail-35--159299133 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We have posted a draft agenda (see below) for the upcoming RMT WG = meeting. The main points are: 1) Making the needed changes to the FLUTE draft (we reached consensus = (thanks Rod Walsh!) on giving the revised FLUTE a new version number). 2) Discussion of the UOD document = (http://tools.ietf.org/html/draft-luby-uod-raptorq-00) status (should it = be a WG document?) that was submitted at the last meeting. 3) Related to #2, there is now a new draft = (http://tools.ietf.org/html/draft-roca-rmt-goe-fec-00) that discusses a = similar scheme for Reed Solomon codes and the authors have performed = some comparison study to UOD proposal and there is discussion time for = this in the agenda. Please try to read the relevant drafts before this meeting.=20 DRAFT AGENDA: 1) Agenda Bashing 5 min - All - sign blue sheets & state your name at the microphone 2) WG Progress=20 5 min - WG Chairs & Document Editors * DOCUMENT STATUS - SUBMITTED FOR PUBLICATION: - draft-ietf-rmt-flute-revised-12 - draft-ietf-rmt-simple-auth-for-alc-norm-04 - draft-ietf-rmt-bb-fec-raptorq-06 - PENDING SUBMISSION - draft-ietf-rmt-sec-discussion-06 - draft-ietf-rmt-fcast-03 (WG Chair Comments) - ACTIVE DRAFTS: - draft-ietf-rmt-flute-sdp-00 - "NEW" DRAFTS: - draft-luby-uod-raptorq-00 - draft-roca-rmt-goe-fec-00 3) FLUTE Update 10 min - Document Authors? - draft-ietf-rmt-flute-revised-12 4) "Simple Authentication Schemes" Update 10 min - Vincent Roca - draft-ietf-rmt-simple-auth-for-alc-norm-04 5) FCAST Update 5 min - Vincent Roca - draft-ietf-rmt-fcast-03 6) Generalize Object Encoding (GOE) for GF(8) RS Codes 10 min - Vincent Roca - draft-roca-rmt-goe-fec-00 7) GOE and UOD Comparison 15 min - Vincent Roca - draft-luby-uod-raptorq-00 and draft-roca-rmt-goe-fec-00 best regards, Brian Adamson brian.adamson@nrl.navy.mil --Apple-Mail-35--159299133 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii We = have posted a draft agenda (see below) for the upcoming RMT WG meeting. =  The main points are:

1) Making the needed = changes to the FLUTE draft (we reached consensus (thanks Rod Walsh!) on = giving the revised FLUTE a new version = number).

2) Discussion of the UOD document (http://tools= .ietf.org/html/draft-luby-uod-raptorq-00) status (should it be a WG = document?) that was submitted at the last = meeting.

3) Related to #2, there is now a new = draft  (http://tools= .ietf.org/html/draft-roca-rmt-goe-fec-00) that discusses a similar = scheme for Reed Solomon codes and the authors have performed some = comparison study to UOD proposal and there is discussion time for this = in the agenda.

Please try to read the relevant = drafts before this = meeting. 


DRAFT = AGENDA:

1) Agenda = Bashing
   5 min - All
   - sign = blue sheets & state your name at the = microphone

2) WG = Progress 
   5 min - WG Chairs & Document = Editors

 * DOCUMENT = STATUS

 - SUBMITTED FOR = PUBLICATION:
   - = draft-ietf-rmt-flute-revised-12
   - = draft-ietf-rmt-simple-auth-for-alc-norm-04
   - = draft-ietf-rmt-bb-fec-raptorq-06

 - = PENDING SUBMISSION
   - = draft-ietf-rmt-sec-discussion-06
   - = draft-ietf-rmt-fcast-03 (WG Chair = Comments)

 - ACTIVE = DRAFTS:
   - = draft-ietf-rmt-flute-sdp-00

- "NEW" = DRAFTS:
   - = draft-luby-uod-raptorq-00
   - = draft-roca-rmt-goe-fec-00

3) FLUTE = Update
   10 min - Document = Authors?
   - = draft-ietf-rmt-flute-revised-12

4) "Simple = Authentication Schemes" Update
   10 min - Vincent = Roca
   - = draft-ietf-rmt-simple-auth-for-alc-norm-04

5) = FCAST Update
   5 min - Vincent = Roca
   - = draft-ietf-rmt-fcast-03

6) Generalize Object = Encoding (GOE) for GF(8) RS Codes
   10 min - = Vincent Roca
   - = draft-roca-rmt-goe-fec-00

7) GOE and UOD = Comparison
   15 min - Vincent = Roca
   - draft-luby-uod-raptorq-00 and = draft-roca-rmt-goe-fec-00

best = regards,

brian.adamson@nrl.navy.mil<= /div>





= --Apple-Mail-35--159299133-- From internet-drafts@ietf.org Tue Jul 26 16:39:44 2011 Return-Path: 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 874AD21F86BF; Tue, 26 Jul 2011 16:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 GEWy4AkVz6L3; Tue, 26 Jul 2011 16:39:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAB521F869C; Tue, 26 Jul 2011 16:39:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110726233944.28167.18352.idtracker@ietfa.amsl.com> Date: Tue, 26 Jul 2011 16:39:44 -0700 Cc: rmt@ietf.org Subject: [Rmt] I-D Action: draft-ietf-rmt-fcast-04.txt X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 23:39:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Reliable Multicast Transport Working = Group of the IETF. Title : FCAST: Scalable Object Delivery for the ALC and NORM Pro= tocols Author(s) : Vincent Roca Brian Adamson Filename : draft-ietf-rmt-fcast-04.txt Pages : 33 Date : 2011-07-26 This document introduces the FCAST object (e.g., file) delivery application on top of the ALC and NORM reliable multicast protocols. FCAST is a highly scalable application that provides a reliable object delivery service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-fcast-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rmt-fcast-04.txt