RE: Plan for moving forward

["Dan Wing" <dwing@xxxxxxxxx>]

> > 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