Subject: [MMUSIC] draft-ietf-mmusic-kmgmt-ext-04.txt: Fallback mode?

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Fri, 17 May 2002 16:08:13 +0200

It is my understanding that the current key-management extension mechanism
does not have built-in any capability to fall back immediately to insecure,
normal RTP profile in case when the recipient has not implemented any
security. My interpretation of the lines below is that the recipient rejects
the offer and the sender would have to initiate a second attempt, this time
without key management extensions included.

>> Note that if the key management protocol fails, e.g., the
   receiver does not accept any of the proposed security parameters, or
   simply does not understand the key management protocol, the security
   setup will fail. Consequently, it is impossible to establish a secure
   session. This is very similar to the normal SIP/SDP behavior: if the
   sender supports codecs which are not supported by the receiver, it
   will be problematic to set up a session.

...

If the answerer cannot support the
   proposed protocol, it rejects the offer.

...

If the offer is not accepted, the answerer
   returns a notification message and the offerer may go out with a new
   (different) offer, depending on the local security policy.

...
<<<

How does the mechanism behave in practice for all those SDP reception end
points that do not have implemented the kmgt-ext? If there such thing as
default reject for any attribute not understood?

Wouldn't it be a good idea to define a particular mode in the kmgt-ext such
that Bob without SRTP AVT profile implementation returns an answer
indicating support of unsecured RTP AVT profile; thus saving one extra
roundtrip?

With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 47713
| ICN M SR 3                     mailto:[email-masked]
|                                mailto:[email-masked]
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Fredrik Lindholm" <[email-masked]>
Date: Fri, 17 May 2002 18:45:46 +0200

> indicating support of unsecured RTP AVT profile; thus saving one extra

No. I do not see the point of an immediate fall back mechanism to something
insecure. If the offer fails, I think it is ok to let the offerer have time
to think over the situation and send out a new offer if it is ok with an
insecure
communication. Anyway, it is not the key-mgmt extensions problem to define
negotiation of profiles (I would guess that's the offer answer model it
belongs
to).  If such mechanism would be used, it would open up for a very easy and
dangerous attacks (and as I see it, more or less inviting attackers to
attack them
by telling, already in the first offer, whether they will accept an insecure
channel
or not)). An attacker (man-in-the-middle) could simply strip the SAVP
profile
from the SDP, and the answerer wouldn't understand this, while the offerer
would happily accept the insecure fallback.

Fredrik