> 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>
> 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
True, privacy through SSH is overkill but strong AUTH is *critical*, I feel:
- TCP-MD5 should not be considered (as it is any ways deprecated and it's
MD5)
- TCP-AO has only slight advantage as it has less overhead than ipsec-AH
even when
deployed with manual keys
- but it's better if it is "MUST support authentication of nodes with TCP-AO
or ipsec-AH" because
as both support
- strong auth algos
- algo agility
- can be deployed with manual and auto key management
(auto key probably required eventually, once with lot of
connections at
cache/global RPKI/server side and for automatic key
changes periodically)
- key changes for existing sessions
One would get flexibility with this.
Also Section 7 (page 16)
"It is assumed that the router and cache have exchanged keys out of band by
some reasonably secured means"
This will be still applicable but only if TCP-AO/ipsce-AH are deployed with
manual keys.
2 cents,
-Uma
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
