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