Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

[Christopher Morrow <[e-mail]>]

a kind reader thunked me on the noggin'...

On Fri, Jun 3, 2011 at 2:06 AM, Christopher Morrow
<[e-mail]> wrote:
> Security-AD folks,
> Over here in the SIDR WG we've been batting around a problem related
> to secure authentication of TCP endpoints, essentially how can we
> specify TODAY something to use in implementations of a (we think)
> important protocol when the underlying technology we need isn't
> available (TCP-AO). Some background:
>
> Looking to close the issue of MD5/TCP-AO/SSH/etc out again, The doc:
> <http://tools.ietf.org/wg/sidr/draft-ietf-sidr-rpki-rtr/>
>
> Seems to be stuck on this text:
>
> (From the abstract)
> " This document describes a protocol to deliver validated
>   prefix origin data to routers over ssh."
>
> or a more in depth version of that text at:
> <http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-12#section-7>
>
> Essentially there is a need to validate that a cache and a router are
> talking to the right opposite entity. The authors and
> test-implementors enabled this connection over SSH with a fallback
> (for debugging I suppose?) over plain-text TCP originally. For a host
> of reasons SSH is now considered overkill and likely detrimental to
> the cause.
>
> The WG discussed on-list (in this thread):
> <http://www.ietf.org/mail-archive/web/sidr/current/msg02397.html>
>
> and at the in-person meeting in Prague (IETF80) the fact that SSH was
> probably overkill. The two endpoints want simply  to authenticate the
> other endpoint, transport security isn't required here because the
> content in the stream is already encypted. The 2 methods approved
> today for use in IETF protocols are:

'the content in the stream is public data, so privacy isn't warranted
here.' Essentially make sure you talk to the right end point and no
one fiddled bits during transport (which AO and MD5 and AH all do just
fine, modulo the 'md5 is deprecated' discussion, of course)

apologies for the confusion, and... for not ending with:

-Chris
<wg-co-chair-utility-belt==unfastened>
>  o tcp-AO
>  o ipsec AH
>
> one deprecated method is available as well:
>  o tcp-MD5
>
> Of the two approved methods, AO has no implementations on the routers
> (yet), nor server side to speak of, AH is relatively heavy weight and
> isn't always available on routers today. Talking to routing equipment
> implementors (two vendors) there was a feeling that AO will arrive
> shortly while AH is still too complex (for router deployments) and is
> not going to be available in all of the platforms which will require
> this functionality.
>
> On the server side of the equation there is no support for AO, some
> for AH (which is nice actually). In short, we don't have a good
> direction or belief that there is going to be one with respect to AO
> in the near term.
>
> What options are there for this problem? How can we motivate vendors
> with a spec that clearly has problems in implementation (no AO, not
> full reach for AH)? Are there folks who are tracking availability of
> AO? Could we start with something like:
>
> MAY support authentication of nodes with TCP-MD5
> MAY support authentication of nodes with IPSEC-AH
> MUST support authentication of nodes with TCP-AO
>
> Or is mentioning TCP-MD5 verboten? Essentially it seems that the WG
> has gotten wedged and is looking for some guidance from the Security
> Area Directors :)
>
> -chris
>