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)