Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 23 jun 2010, at 00.59, Thomson, Martin wrote:

> It seems that Section 7 has an old example in it.  Did you previously use NAPTR with a "D" flag?

Actually, no. If you do know what protocol you look for, you can use the URI RR directly. The idea with the NAPTR and the "D" flag was that it would list what URI records exists in the zone.

Let me expand a bit also including the caldav example:

$ORIGIN example.com.

     IN NAPTR 200 10 "D" "EM:protA"  (      ; service
     ""                                     ; regexp
     "example.com."                  )      ; replacement

     IN NAPTR 200 10 "D" "caldav:caldav"  (      ; service
     ""                                     ; regexp
     "example.com."                  )      ; replacement

     IN NAPTR 200 10 "D" "caldav:carddav"  (      ; service
     ""                                     ; regexp
     "example.com."                  )      ; replacement

_protA._EM IN URI "prota://somehost.example.com/"

_carddav._caldav IN URI "http://somehost.example.com/whateveruri";

_caldav._caldav IN URI "http://somehost.example.com/someotheruri";

I.e. if you know you want the carddav/caldav URI, you just look up the {IN,URI,_carddav._caldav.example.com} RRSET, if you want to know the services example.com has, you look up {IN,NAPTR,example.com} and then with flag "D" you see what you can find using lookup of URI RR.

So, the NAPTR and flag "D" is not really needed for the resolution. It is a "list the services" feature.

But, I will remove that part because it is not really a piece of the URI definition.

> 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.

   Patrik


> I'm happy to expand on the problems that I faced with this little security tangle.  The problem doesn't end there.


Attachment: PGP.sig
Description: This is a digitally signed message part

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]