Hannes,
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Hannes Tschofenig > Sent: 26 June 2008 11:26 > To: Elwell, John > Cc: [email protected]; Paul Kyzivat; Dan Wing > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > > >> http://tools.ietf.org/html/draft-ietf-sip-certs-06 > >> > > [JRE] I don't understand - how does sip-certs provide end-to-end > > authentication? It might help me to locate a certificate > that is used in > > some authentication mechanism such as Identity, but it > doesn't itself > > provide an authentication mechanism. > > > > John > > Two of the current proposals to fix SIP Identity combine it with > DTLS-SRTP. An alternative is to use SIP CERT with DTLS-SRTP. [JRE] So you propose having certificates in the UAs, and have these deployed using sip-certs? I wonder whether this meets the requirement: "R-CERTS: The key management protocol MUST NOT require that end-users obtain credentials (certificates or private keys) from a third- party trust anchor." Does the credential server count as a third party trust anchor? If so, we would not meet this requirement. But assuming the server is in the same domain as the UAs it supplies credentials to, it is probably not considered third party and probably meets the spirit of the requirement. Also, I think there would need to be some adaptation of sip-certs. For example, sip-certs explicitly says it is for use with S/MIME. Also, as you pointed out, this too relies on RFC 4474 (but in a NOTIFY). Maybe HTTPS would be more appropriate for this part. If Bob has several UAs, each would receive the same private key and cert from the credentials server. I don't know whether this has any implications for DTLS-SRTP (c.f., self-signed certs, which would doubtless be different in each UA). Similarly to some of the other alternatives, this would provide an authenticated identity for DTLS-SRTP, but not for calls that don't use DTLS-SRTP, and also not for SIP requests not related to calls such as MESSAGE, SUBSCRIBE, NOTIFY, and also not for mid-dialog requests that don't include SDP (where the certificate fingerprint resides), such as BYE, offerless UPDATE, the dreaded INFO. Intermediate domains would need to pass SUBSCRIBE/NOTIFY requests - this might be almost as big an ask as requiring them not to interfere with an RFC 4474 certificate. Alternatively, perhaps enterprises etc. that insist on intermediaries for calls might open their doors to direct peering for SUBSCRIBE/NOTIY. I can still see issues with the actual identity. For example, with an E.164 number, I send [EMAIL PROTECTED] in From or PAI, but by the time it reaches you it has been changed to [EMAIL PROTECTED], so your UA would send the SUBSCRIBE request to [EMAIL PROTECTED], and that would somehow need to reach [EMAIL PROTECTED] But yes, this is an alternative approach worthy of further exploration. John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
