Re: Plan for moving forward

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

At Sat, 2 Jun 2007 09:57:28 -0700,
Dan Wing wrote:
> 
> 
> > > One of the applications I recently 
> > > came across  
> > > has the Caller having the Callee authenticate first and within the  
> > > resulting secure channel use a legacy method to authenticate itself.
> > 
> > Well, before the Montreal BOF would have been the place and time to  
> > bring up that requirement. Luckily, I think you are pretty safe in  
> > that this requirement is supported by the solution we are on. SIP  
> > allows an INVITE to have and offer and also allows INVITES 
> > without an  
> > offer where the UAS sends the offer. I think this will meet your  
> > requirement.
> 
> 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.

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.

-Ekr