Thanks Matt. I know of cases where skipping the self-signed cert on the UAC side would be considered necessary. Broadly speaking whereas verifying server-side certs as in case of https is alright, client-side certs, self-signed or not, are not really viable at the moment. Perhaps in the distant future, we don't need such optimizations, but for now optimizations at call set-up are good.
regards, Lakshminath On 6/7/2007 11:09 AM, Matt Lepinski wrote:
Lakshminath,If I understand correctly, you're saying that there are use cases where the UAS does not care whether the entity with whom he's conducting a DTLS exchange is the same entity who sent the SIP INVITE. (Because the UAS knows that immediately following the DTLS exchange, the UAS will authenticate using "legacy methods").I do not know how common such use cases are.My question is: In such use cases, is it really too much of a burden to ask the UAC to generate a self-signed cert to use in the a=fingerprint attribute and the DTLS exchange? That is, perhaps there are use cases where the security guarantees provided by tying the signaling to the DTLS exchange are not needed. However, to avoid adding an additional special case to the specifications that we will produce, perhaps it is reasonable to ask the UAC to generate a self-signed cert for use in the a=fingerprint attribute (and subsequent DTLS exchange)?My bias is that unless the use-cases in question are quite common, and the computational burden is excessive, it is better to provide the additional security guarantees in all cases (even if in some cases the guarantees are strictly necessary).- Matt Lepinski :-> Lakshminath Dondeti wrote:I agree that it has a purpose when it is necessary to identify the device, but I am making the case that identifying the device is not necessary in all cases.regards, Lakshminath On 6/7/2007 10:40 AM, Richard Barnes wrote:Lakshminath,The first authentication does have a purpose. It authenticates that DTLS endpoint is the same as the signaling endpoint by providing a certificate that matches the a=fingerprint attribute in the signaling. That cert could be self-signed or signed by a third party, but the binding works becuase the same cert was used in the a=fingerprint and in the DTLS exchange.--Richard Lakshminath Dondeti wrote:Eric,I definitely understand the mode of operation you are talking about, but the point is that the caller has to authenticate twice, first with a self-signed cert and then later using DTMF digits. In some cases, the first authentication has no real purpose, so why can't we skip it? That's what I am getting at.regards, Lakshminath On 6/7/2007 6:10 AM, Eric Rescorla wrote:At Wed, 06 Jun 2007 23:16:58 -0700, Lakshminath Dondeti wrote:Thanks for your note. One of the successful models with certs and PKI we have is the https model. The use case I am putting forth works along those lines. The caller is the client and the callee is the server; the server, e.g., a calling card server or a priority call processing server, authenticates itself first; the client authentication is optional as DTLS allows and within the secure tunnel the caller sends DTMF tones as RTP packets to enter the calling card information or priority codes.That use case came up in a discussion recently. It is not "future work" in my opinion. It is also not dramatically different from what we have been discussing either.It's also totally compatible with DTLS-SRTP as-is. Remember, the DTLS client and serve authentication here are for the purposes of binding the DTLS handshake to SIP not necessarily for the purposes of binding the DTLS-SRTP to an identity. So, in this case, what would happen is that both parties would DTLS authenticate with their self-signed certs. Optionally, callee could use their third-party cert instead. Once the media stream is established the client enters DTMF over the secure media stream.Note that this works no matter which side takes on the DTLS client/serverrole, which, btw, is an issue totally orthogonal to who is the callee or caller. -Ekr