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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Eric,

Agreed on the editorial feedback, and thanks. Notes on the technical
issues below - I think we agree on most.

Joe

Eric Rescorla wrote:
> $Id: draft-ietf-tcpm-tcp-auth-opt-05-rev-real.txt,v 1.1 2009/07/26 22:18:40 ekr Exp $
> 
> This draft seems to resolve all my major technical issues.
> The comments below are primarily editorial.
> 
> 
> TECHNICAL
>    The relationship between MKTs and traffic keys is shown in Figure
>    Figure 3. Traffic keys are indicated with a "*". Note that every MKT
>    derives all four traffic keys, regardless of whether all four are
>    needed for a given connection. Section 7.2 provides further details
>    on how traffic keys are derived.
> 
> 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.

...
> S 9.5.
> As I read this description, if an implementation receives a TCP segment
> with TCP-AO but it doesn't match any existing MKT, it should silently
> accept it. I don't agree with this. It should discard it. It's clearly
> not valid.

Agreed. The original intent was to allow communication with an endpoint
that didn't have an MKT, but that clearly won't work because MKTs cover
both directions, and thus the ACKs won't be received anyway.

>            i. If lengths differ, silently discard the segment. Log
>                and/or signal the event as indicated in Section 9.3.
> 
> I observe that this logging suggestion has the possibility to be
> a DoS in and of itself. If we're going to recommend logging,
> we need to recommend log throttling.

I thought we had; I'll check and add or add a reminder.

> 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.

...
>       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"

...
>       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.

...
...
> 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.

If it matches no MKTs, TCP-AO is not used.

> - Any incoming packet must match either one or zero MKTs.

If it matches zero MKTs and has TCP-AO option, then it must be dropped.

If it matches one or more MKTs and has no TCP-AO option, then it must be
dropped.

> Is there any disagreement that this is correct? If so, I recommend
> rewriting the text to contain more or less just this.

As per above, the full set of cases needs to be discussed here. Granted
the text can be revised to avoid "preferred" keys as per above.

...
> S 6.
> Current_Key and Next_Key seem confusing here because we're punning
> on the use of key.

Agreed - should change that to "current_MKT" and "next_MKT".

> - Conenctions must store the current traffic keys (or enough information
>   to regenerate them). They must also store the key-id needed to indicate
>   those traffic keys.
> 
> - The SNEs.
> 
> 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.

Connections need to either store the traffic keys or the info to
generate them. The latter would include the ISNs. I'll list the info
needed to generate them instead of storing the keys.

> 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.

Otherwise, we need two versions:
	
	1) the API between TCP-AO and Gregory's doc

	2) the API between Gregory's doc and the MAC alg.

Gregory's doc focuses on parameters; TCP-AO describes the algs and
interfaces, so I think it's important to include this here - even though
it's an opaque 'pass-through' value.

> S 7.2.
>    o  Output_length - The desired output length of the KDF, i.e., the
>       length to which the KDF's output will be truncated. In TCP-AO, the
>       output_length is the PRF_truncation value of the MKT. This is
>       specified by the KDF as described in [ao-crypto].
> 
> Everything from i.e., seems (1) superfluous and (2) isnufficiently
> general. Who says the PRF is truncated?

Again, I was describing a general alg from Gregory's doc. If that's
never an arg to a PRF, then we can omit it in TCP-AO.

...
>    We encourage users of TCP-AO to apply known techniques for generating
>    appropriate MKTs, including the use of reasonable master key lengths,
>    limited traffic key sharing, and limiting the duration of MKT use
>    [RFC3562]. This also includes the use of per-connection nonces, as
>    suggested in Section 7.2.
> 
> This seems like old text. We don't encoruage people to use per-connection
> nonces, it's part of the protocol.
...

"It" here is TCP-AO, not the user. That should be revised to be more clear.

> 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.

> 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.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkptkL8ACgkQE5f5cImnZrutgQCeMYlz00TM43zbPeLsLurLb+1i
PasAn0T0Ct/BbBFBlx6grIkIKMcsln8M
=bGeu
-----END PGP SIGNATURE-----