For security considerations, I have one to add. RFC 3958 (S-NAPTR)
has this nasty little authentication hitch, that you should really
consider in this draft. The reference identifier (see draft-
saintandre-tls-server-id-check) that you are required to use for
authenticating the host is the one that is input to the resolution
process...not the product of the process.
Basically, if you search for _http._web.example.net and get "http://www.example.com/
", then you are expected to authenticate against _http._web.example.net
(or maybe example.net, I'm not sure - NAPTR doesn't use the '_'
prefix).
I thought you should authenticate against example.net?
I.e. you want "caldav"/"caldav" for "example.com" and get back "http://www.calendarserverfoobar.com/caldav/example.com/caldav
" (for a PROPFIND), what is the best to require for authentication?
example.com or www.calendarserverfoobar.com? I presume example.com
(the domain name used _before_ the URI lookup happens.
In principle, example.com is the proper domain to authenticate, but in
practice, that causes a lot of problems. Consider the case where the
target of the redirection is a separate entity from the origin; this
could arise, for example, in a situation where example.com has
outsourced its calendaring services to calendardserverfoobar.com.
Then requiring the target domain to authenticate as the origin (i.e.,
as example.com) means that you're enabling the outsourced calendaring
provider to authenticate as their customer, which requires them to
keep different keys for each customer and present different certs on
different connections (which may or may not be feasible depending on
how customer resources are distributed in the provider infrastructure)
-- and invites the risk of abuse.
On top of that, there's the implementation issue that a lot of
libraries (for HTTP, but others as well) don't let you authenticate
any identifier than the domain name in the URI.
One flavor of this problem is being worked in XMPP now. They're
creating Domain Name Assertions so that the origin domain can create a
signed object attesting to the delegation and the target domain can
authenticate as itself.
<http://tools.ietf.org/html/draft-ietf-xmpp-dna-00>
But it's clearly a more general problem. Stpeter and I are planning
to organize a bar BoF about it in Maastricht, but in the spirit of
having more ad-hoc bar BoFs, we haven't done any concrete planning.
--Richard
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf