Pekka, Thanks for the quick response.
On Wed, 2009-01-07 at 11:44 -0600, Pekka Pessi wrote: > tpn_subject breaks the binary compatibility I was wondering if that would be an issue. The point was to get the subject into vtp_connect() and perform subject verification before tport_send_event() was called. I should be able to move the tpn_subject field to somewhere in else in the tport_t structure. > Also, if we want to do some automated Subject testing at tport level, > I'd go for using tpn_canon which should contain the domain name used > in the SIP URI. There is a serious pitfall here. When sending to sips:b...@biloxi.com a DNS lookup takes place that that resolves _sips._tcp.biloxi.com to an A record. Through various mechanisms, an attacker could fool the resolver into believing that the UAC should connect to sip.mitm.com (which will be listed in tpn_canon, I think?) and defeat the security mechanism altogether. I did think of adding a parameter list onto tpn_canon, but that is probably more trouble than its worth. > For more hairier cases, perhaps tags in tport_tsend() arguments > containing the desired subject (e.g., TPTAG_X509_SUBJECT or > TPTAG_X509_SUBJECT_DN, TPTAG_X509_SUBJECT_DNS, > TPTAG_X509_SUBJECT_RFC822, and TPTAG_X509_SUBJECT_URI)? This is probably the way to go. I also want to add TPTAG_X509_CA_STORE() and TPTAG_X509_AGENT() so that an application can implement something like this: http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-07.txt > If we are > trying to send an INVITE to sip:b...@biloxi.com, the peer certificate > could contain subjects like URI sip:biloxi.com, sips:biloxi.com, > dNSName biloxi.com (and in case they use NAPTR) dNSname > ext-sip-proxy.biloxi.com. Likewise, incoming connection from > sip:al...@atlanta.com could have URI sip:al...@atlanta.com or > rfc822Name al...@atlanta.com. So perhaps nta or upper layers could > build a list of possible subjects and include them with the > tport_tsend(). AFAIK, sips: is regarded as invalid for cert subjects. To go with the theme above (don't trust DNS with anything) using DNSNames from NAPTR lookups is out of the question. Interchanging sip:b...@biloxi.com with sip:biloxi.com may seem ok ... but it is reasonable to think that sip:mall...@biloxi.com might exist as well. Peer review would be appreciated here. In all the cases I have came up with, there is only one subject that should be verified for any one outgoing message: * The IP or fqdn - sip.atlanta.com or 1.2.3.4 - of an outbound proxy; * a SIP User URI - sip:al...@atlanta.com - for direct connections; or * a SIP Domain Identity - sip:biloxi.com - for interdomain requests; Ultimately, it is up to tport_subject_search() to match a request for sip:biloxi.com to the DN biloxi.com - such exceptions can be added as they are identified. The exceptions that need to be identified are the instances where it is reasonable to match more than one subject for any one message. > Why sip:foo.bar.com matches w/ *.bar.com but not with foo.bar.com? > It is good you rejected that patch, because neither of those worked ;) When I resubmit, wildcard subjects will be disabled. It seems the opinions at IETF disapprove of them (and frankly, I concur). http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-02.txt I will comment the (fixed) wildcard code should mob opinion change in the future. ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
