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

Re: Plan for moving forward


Hannes,
Vesa and I may be talking about two different things. Vesa, if you are following the list, please see below for a description of the use case I am talking about. 

On 6/2/2007 11:57 AM, Hannes Tschofenig wrote:
This discussion very much reminds me to the discussion we had with Vesa Lehtovirta a little bit more than a month ago. He also had the requirement that "existing credentials" should be reused. Whether this works or not depends heavily on the architecture and the way how you would like to integrate them into the overall solution. If you use, let's say, the UMTS authentication algorithm between the SIP UA and the P-CSCF then you can obviously use the SIP Identity mechanisms from the P-CSCF towards the other SIP endpoint.
In our previous discussion with Vesa we requested more details and we never got them. Now, Lakshminath seems to have also a solution in mind but without the details it is hard to figure out whether it works.
I don't have a solution in mind really. I just came across a use case recently. All I am saying is that we should facilitate that use case.
You are familiar with the IKEv2 model: The Initiator authenticates first in the "normal" case. However, it has an option to skip the authentication and ask the Responder to authenticate first and then use EAP to authenticate itself.
Let's say I have a phone which has the certificate of a gateway. Using that phone, I should be able to call that gateway, have the gateway authenticate itself, establish a secure channel, authenticate the phone to the gateway, and securely communicate with that gateway. How the phone gets access to the SIP network is independent of the authentication credentials used to authenticate to the gateway. 



I wonder why these details have not been shared with the group already....


I came across this use case recently (well after the Prague meeting).

thanks,
Lakshminath



Dan Wing wrote:

I don't think flipping who sends the offer is sufficient -- DTLS-SRTP,
as the several documents are now, uses a=fingerprint to authenticate
both endpoints.  What Lakshminath is looking for is a way for one side
to declare that they don't want their certificate used as the authentication mechanism, but rather wants something else used (a 
password or something; 'legacy method' encompasses a lot of stuff).

Hmm... I realize we're used to thinking of certificates as a form
of authentication, but I think that leads people off track in
this case. In DTLS-SRTP, the authentication at the DTLS layer serves primarily to bind the authentication performed in the signalling plane to the cryptography being done in the media plane. That's why it's OK for the certs to be self-signed and 
just authenticated via fingerprint.


Yes, but in conjunction with SIP-Identity (RFC4474) you get
authentication -- if, of course, you trust the entity that created that RFC4474 signature. I don't usually think of DTLS-SRTP 
without SIP-Identity, myself -- without SIP-Identity, you're getting
little more than opportunistic encryption (unless you store the
certificate you used last time with that same party, and/or read each other's certificate fingerprints or something akin to that). 


I would argue that from an architectural perspective if you
want another form of authentication (e.g., EAP) you should
put that at the SIP layer. Remember, there are plenty of contexts
in which you need to trust the other endpoint where no media streams
are set up between you.


Yes, that could be useful for SIP itself.

-d