Subject: [karp] Karp-threat-reqs 2.2, tcp-ao comments (was "Karp-threat-reqs Updated")

From: Gregory Lebovitz <[email-masked]>
Date: Fri, 23 Mar 2012 10:52:25 -0700

thread subject was: Karp-threat-reqs Updated
Specifying to: "Karp-threat-reqs 2.2 & tcp-ao comments"

On Wed, Mar 21, 2012 at 11:28 AM, Joe Touch <[email-masked]> wrote:

> Some comments and questions below.
>
> Joe
>
> ----
>
> Current Sec 2.2 (incremental approach)
>
> The last sentence (which is repeated) appears to raise issues with TCP-AO,
> but the concerns are already addressed in TCP-AO's design - AO already
> prevents replay attacks, allows TCP connections to restart without the need
> to install new keys at the endpoints, and supports different crypto
> algorithms.
>
> What are the concerns here?
>

Good catch, Joe. This is text rot from when we first started this draft
years ago, and were right in the middle of the -AO effort together. It
should only be an example of how we took an incremental approach. How is
this for replacement text:

   Last, some security mechanisms require the build out of other

   operational support systems, and this will take time.  An example
   where these three reasons were at play in an incremental improvement
   roadmap was seen in the improvement of BGP's [RFC4271
<http://tools.ietf.org/html/rfc4271>] security via
   the TCP Authentication Option (TCP-AO) [RFC5925
<http://tools.ietf.org/html/rfc5925>] effort.  It would have been
   ideal, and reflect best common security practice, to have a fully
   specified key management protocol for negotiating TCP-AO's keying

   material, e.g., using certificates for peer authentication.
However,in the spirit of incremental deployment, we first addressed
issues
   like cryptographic algorithm agility, replay attacks, TCP session
   resetting in the base TCP-AO protocol, and then later layered key management
   on top of it.
?

-- 
----
IETF related email from
Gregory M. Lebovitz

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Mar 2012 07:19:12 -0700

Hi, Gregory,

On 3/23/2012 10:52 AM, Gregory Lebovitz wrote:
> On Wed, Mar 21, 2012 at 11:28 AM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     The last sentence (which is repeated) appears to raise issues with
>     TCP-AO, but the concerns are already addressed in TCP-AO's design -
>     AO already prevents replay attacks, allows TCP connections to
>     restart without the need to install new keys at the endpoints, and
>     supports different crypto algorithms.
>
>     roadmap was seen in the improvement of BGP's [RFC4271  <http://tools.ietf.org/html/rfc4271>] security via
>     material, e.g., using certificates for peer authentication.  However, in the
 >     spirit of incremental deployment, we first addressed issues

I don't think that's accurate; TCP-AO left out keying for a variety of 
reasons, but incremental deployment wasn't one of them. The reasons, 
AFAIR, were:

	1) TCP's handshake was deemed insufficient to support useful
	keying due to lack of SYN option space

	2) TCP-AO was specified as just the mods to TCP

	3) TCP-AO was intended to be independent of the keying mechanism

	4) the development of a keying protocol was deemed out
	of scope for TCPM

I.e., it was at best an issue of incremental development of the 
components of the solution, but incremental *deployment* was not a 
consideration I ever recall being raised.

Joe