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: 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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
