Subject: [Sip] Question to Identity draft & cert draft

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Apr 2005 18:40:35 -0400

Cullen/Jon, 

I'm a little confused by the following paragraph in
draft-ietf-sip-identity-04
in section 10:

   The Identity-Info header MUST contain either an HTTPS URI or a SIPS
   URI.  If it contains an HTTPS URI, the URI must dereference to a
   resource that contains a single MIME body containing the certificate
   of the authentication service.  If it is a SIPS URI, then the
   authentication service intends for a user agent that wishes to fetch
   the certificate to form a TLS connection to that URI, acquire the
   certificate during normal TLS negotiation, and close the connection.

I understand the HTTPS URI case (which is used in the example in 
draft-ietf-sip-identity-04), but I'm not sure I understand the
SIPS URI which is used in draft-ietf-sipping-certs-01. What do you
mean by fetching the certificate through a TLS connection? Why would
sips mean TLS? Do you mean fetch it using a SIP request over TLS?
I don't understand how it works (and why HTTPS is not sufficient). 

Can you elaborate?

I'm keeping this in SIP instead of SIPPING since one draft is SIP the other
is SIPPING.
_______________________________________________
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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 Apr 2005 20:52:05 -0700

> SIPS URI which is used in draft-ietf-sipping-certs-01. 

Hm, I couldn't find a SIPS URI used in -sipping-certs-01.

> What do you 

What I believe is being described is that, TLS client receives the TLS
server's certificate during the TLS handshake.  sip-identity-04 is unclear
if you're supposed to complete the entire TLS exchange, or if you're
supposed to prematurely terminate the TLS exchange to avoid the public-key
operation on the SIPS TLS server.

If you're supposed to prematurely terminate the TLS exchange, you won't get
to the last step of the TLS handshake where TLS checks for a MiM (via the
TLS "finished" messages).

But maybe I interpreted it incorrectly.

For sip-identity, I'm unsure of the advantage a TLS-protected HTTP or SIP
connection affords retrieving a certificate:

1. If an impersonator is able to modify the SIP signaling in transit, the
impersonator will be capable of generating a valid signature using their own
certificate and will provide a URI pointing to the impersonator's
certificate.  However, sip-identity-04's existing comparison of the
subjectAltName to the domain of the URI (section 7, 4th paragraph) should be
sufficient to notice such an impersonation.

2. If an impersonator is UNable to modify signaling, but can be a MiM when
you retrieve the certificate with your non-TLS-protected HTTP or SIP
connection, that certificate won't authenticate the signed identity.

So what's the attack that is mitigated through the use using a TLS-protected
HTTP or SIP connection in retrieving the certificate for sip-identity?

... and I thought you were going to ask why sip-identity didn't use the
SUBSCRIBE/NOTIFY method of sipping-certs, especially considering the common
authors.  Cullen/Jon?

-d

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 22 Apr 2005 14:45:45 -0700

Right now, the draft works as Dan describes below but I have got a ton of
feedback that we need to change that.

I would like to change it to the URI specifies a URI to fetch a certificate
as specified in RFC 2585.

So the URI would look like
http://www.netcom.com/sp/spyrus/housley.cer

It would have to have an file extension of .cer . A normal HTTP GET would be
performed on this and would return a MIME body of type
application/pkix-cert. Inside this body would be the DER encoded X.509 cert.
This is all defined in 2585.

Cullen