1 / 5

67 th IETF (November 5-10, 2006) San Diego, CA (USA)

Domain Certificates in SIP Vijay K. Gurbani, Scott Lawrence, and Alan Jeffrey draft-gurbani-sip-domain-certs-03. 67 th IETF (November 5-10, 2006) San Diego, CA (USA). Problem. What identities appear in a X.509 certificate for SIP clients and servers?

geoffrey-lancaster
Download Presentation

67 th IETF (November 5-10, 2006) San Diego, CA (USA)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Domain Certificates in SIPVijay K. Gurbani, Scott Lawrence, and Alan Jeffreydraft-gurbani-sip-domain-certs-03 67th IETF (November 5-10, 2006) San Diego, CA (USA)

  2. Problem • What identities appear in a X.509 certificate for SIP clients and servers? • The HTTP model: one identity (www.example.com), all servers in a farm share this certificate. • In SIP, this works fine for a request with a high-level URI (sips:alice@example.com), but … • Proxies R-R with their FQDN name (sips:downtown.example.com), so on a subsequent contact, example.com != downtown.example.com. • The system creating a TLS connection may be authoritative for its SIP Domain as a sender without being in the set of proxies resolved by NAPTR/SRV for that domain (outbound vs. inbound proxies).

  3. Solution • Two issues to be solved: • An authoritative way to express the purpose of the certificate: easy for implementers to code against, and CAs to enforce. • Identify the host presenting the certificate. • Draft proposes inserting two identities in the certificate: • sip:example.com => The system is authoritative for the SIP domain that is named. • dns:downtown.example.com => The system is authoritative for the name used as the transport address.

  4. WG List Discussion • Consensus on • having multiple identities in the SAN of the certificate (EKR proposed a list of rules that are appropriate; see http://www1.ietf.org/mail-archive/web/sip/current/msg17028.html) • Do not break the names into sip and dns schemes. • Use OIDs for enunciating the purpose of the certificate • The use of ‘sip:’ URI • The addition of an extendedKeyUsage OID(will be in next version of the draft)

  5. Next Steps • WG interest in pursuing this? • WG item?

More Related