Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05

Eric Rescorla <ekr@networkresonance.com> Mon, 27 July 2009 14:36 UTC

Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9E63A699E for <tcpm@core3.amsl.com>; Mon, 27 Jul 2009 07:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.589
X-Spam-Level:
X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZk8IS-OXq+O for <tcpm@core3.amsl.com>; Mon, 27 Jul 2009 07:36:18 -0700 (PDT)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id EF5783A68FD for <tcpm@ietf.org>; Mon, 27 Jul 2009 07:36:17 -0700 (PDT)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 032251D2EE1; Mon, 27 Jul 2009 07:39:05 -0700 (PDT)
Date: Mon, 27 Jul 2009 07:39:05 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A6D90BF.4050301@isi.edu>
References: <20090726232711.30A7650822@romeo.rtfm.com> <4A6D90BF.4050301@isi.edu>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20090727143906.032251D2EE1@kilo.networkresonance.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2009 14:36:19 -0000

At Mon, 27 Jul 2009 04:34:23 -0700,
> > This seems like an unwarranted requirement. The keys are generated
> > independently, so why make implementations gnerate keys they don't
> > need?
> 
> Agreed - I was trying to say that every MKT *can* derive any of the four
> traffic keys, not that all four *are* always derived.

OK. So this may be editorial only.

> > EDITORIAL
> ...
> > S 2.
> >    Section 9.6). This document obsoletes the TCP MD5 option with a more
> >    general TCP Authentication Option (TCP-AO), to support the use of
> > 
> > s/obsoletes/replaces/
> 
> I thought we needed to use the term "obsoletes" somewhere. Maybe this is
> the right sentence to do so, maybe not.

Well, I think we could rewrite this as.

"This document obsoletes the TCP MD5 option. It replaces it with..."


> ...
> >       Values of 4 and other small values larger than 4 (e.g., indicating
> >       MACs of very short length) are of dubious utility but are not
> >       specifically prohibited.
> > 
> > It's probably worth stating explicitly here that the MAC length is
> > dictated by the MKT, not the option.
> 
> The length of the MAC field is dictated by the option. If the option
> says the MAC is 70 bytes, and the MKT says it should be 72, then the
> packet would fail authentication.
> 
> I'll correct to call this "indicating MAC fields of very short length"

AGreed. I'm just mentioning this so people don't think that you
can specify a shorter MAC in the option and have it validate.


> ...
> >       Implementations are advised to keep master key values in a
> >       private, protected area of memory or other storage.
> > 
> > I'm curious if anyone has a concrete notion of what this means. As I
> > understand the situation, Cisco routers (for example) are a single
> > monolothic process. How would you do this for a Cisco?
> 
> Keep the keys in an area that non-operator processes can't get to
> without explicit permission or override.

Sure. I'm just observing that this isn't true on some systems
which only have one level of securuty.



> > S 5.3.
> > This whole discussion of how many MKTs can match seems confusing
> > and self-contradictory.
> > 
> > My understanding of the rules is as follows:
> > 
> > - Any outgoing packet, which has not yet been processed by TCP-AO,
> >   may match any number of MKTs, but each MKT must have a distinct
> >   key-id. Once that packet has been processed by AO, it must
> >   match only one MKT, determined by key-id.
> 
> If it matches multiple MKTs, the question is whether there is a
> preferred one or not. I had thought there was, but if not then this text
> can be used.

I had sort of assumed that this was an invariant--that the system
had to pick a preference if there were any.


> > There is no need to *store* Next_Key. It can be regenerated every time.
> > What's required is simply that it appear on the wire. I don't see any
> > need to store the MKTs with the connection either. They're "associated"
> > in that they match, I suppose...
> 
> Next_key is a value indicated by the user. It needs to be stored somewhere.

Sure, but it could be a global setting.


> > S 7.1.
> > 
> >    o  MAC_truncation - the number of bytes to truncate the output of the 
> >       MAC to. This is indicated by the MAC algorithm, as specified in 
> >       [ao-crypto]. 
> > 
> > I don't think it makes sense to talk about truncation here.
> > The MACs produce a value that is crammed into the packet.
> > If there's a separate spec that describes the MACs, it's not
> > AO's business whether those MACs were produced by a truncation process.
> 
> We need to describe the function as a call; the details are provided in
> Gregory's doc. Since truncation is an argument to the call, I need to
> indicate it.

Right, I don't think it should be an argument to the call--so it's
Greg's fault :)



> > S 9.5.
> >                      a. Optionally, set a timer on the MKT indicated by
> >                        the current_key and segment socket pair to
> >                        ensure that the MKT cannot be deleted for 2*MSL.
> >                        If a timer has already been set, reset the
> >                        timer.
> > 
> >                        This timer is advisory only. Removing MKTs with
> >                        unexpired timers can result in a user-level
> >                        warning, but is not prohibited. Implementation
> >                        of timers is not required.
> > 
> >                      b. Set Current_key to the NextKeyID MKT.
> > 
> > I would reverse the order of these, since (a) is required and (b) is
> > optional.
> 
> The timer is optional, and shifting keyIDs is required.
> 
> If we shift the order, we would need an intermediate value for
> current_key, since we operate on current_key in (a). The order described
> avoids that. I don't see why we'd reverse the order of these as a result.

OK.

I just think mndatory before optional.


> > S 10.
> > Was TCP-MD5 Mandatory to Implement? If not, this shouldn't be either.
> > Even if so, this seems like kind of an unwarranted requirement.
> 
> Hard to say. RFC793 says all options must be implemented, and separates
> that claim from the list of "currently specified" options. Whatever the
> WG feels is appropriate here is fine.
> 
> IMO, it can't just be optional; it should be manditory at least in some
> environments.

I'm not going to go to the wall on this one. What do others
think?

-Ekr