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

[Eric Rescorla <[e-mail]>]

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