[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Plan for moving forward




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/server
role, which, btw, is an issue totally orthogonal to who is the callee
or caller.

-Ekr