Subject: [Sip] Concerns about draft-ietf-sip-connect-reuse-03

From: "Udi Tirosh (Weintrob)" <[email-masked]>
Date: Wed, 13 Apr 2005 16:29:40 +0300

Hi,

In draft-ietf-sip-connect-reuse-03, section 4.1.1 [3], it is described
that for every mutually authenticated TLS connection, the UAS will have
to perform a routine similar to the one in RFC3263 to find out if the
name in the via is indeed covered by the certificate.
My Concerns regard sections 3 and 4 in the proposed algorithm.

>From connect-reuse-03:
   3.  Use DNS to resolve if the advertised name is resolvable from the
       subjectAltName (start by resolving the subjectAltName as if it
       where a target URI according to the rules in RFC3263.  That is,
       if no port number is present perform an SRV lookup, then finally
       resolve relevant address records).  If any of the resolved
       addresses (port numbers can be ignored in this case) matches the
       advertised address, then the certificate covers the address.
   4.  Finally, Verify that the advertised address can resolve to the IP
       address over which the connection was received.

Firstly, I am concerned with the time it might take to perform that
"reverse 3263" algorithm:
A NAPTR query has to be send, 
If it fails, an SRV query will have to be sent,
And finally (assuming there were no additional info in the DNS server
response) another A query.
So, we end up with 3 DNS queries for one resolution.
The thing that can be troubling is that an administrator can have
multiple SRV records (load balancing, for example). Each will result in
several hosts, so more A queries have to be done until the "advertised
address" can be verified.
Lastly, the subjectAltName field in a TLS certificate is a list, so, it
can have multiple addresses (e.g. proxy.com, proxy.org, proxy.co.uk).
Now which one of those should we use? Again trying them all can be very
time costly and heavy on network traffic.

Another concern I have regard using DNS as means of authentication.
Requests sent to and responses received from DNS server are usually over
UDP and can be intercepted and changed.

Maybe a solution for the multiple SRV records issue, can be to add a
parameter to the via: expected-srv:<the srv to use from the NAPTR
record>. Empty expected-srv can indicate that there are no NAPTR
records.

Regards,
Udi J. Tirosh.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip