Subject: [MMUSIC] <draft-ietf-mmusic-kmgmt-ext-05.txt>

From: "Elisabetta Carrara (EAB)" <[email-masked]>
Date: Tue, 22 Oct 2002 14:28:45 +0200

Hi
we have had the work for integrating a key management protocol 
into SIP/SDP and RTSP for a while, in order to be able to negotiate 
keys and parameters for SRTP in a secure way. This work originated from 
some other work done in IETF: the MIKEY protocol in the MSEC WG
(where the draft has now completed the WG Last Call) and the SRTP
protocol in the AVT WG (the draft is now under IESG review).
One of the main motivations to include the key management into SIP/SDP 
and RTSP is to have a low latency (as the number of roundtrips for 
setup can be reduced by this approach). 

The integration of the key management protocol into SIP/SDP 
and RTSP is a missing piece, and the draft has substantially 
not progressed for a number of meetings now. Therefore, we would 
like to take a decision together with the group in order to 
go further.

The issue we have is the choice of a 'blob' approach vs an explicit 
description of the attributes. The blob approach consists of using 
the binary encoding that the standalone protocol (i.e. MIKEY)
uses. The explicit approach would consist of encoding the information
present in the binary protocol into a textual format and link its 
usage to the state machines of SIP and RTSP.
Our draft follows the blob approach, with a base64 encoding 
of the binary MIKEY; however some people expressed that they 
preferred a text-based approach. 
We listed our motivations in an old mail to the mailing list, 
however here are the main reasons why we like the blob approach:

- Modularity. MIKEY is not the only key management existing. It is 
	easy to reuse the blob for other protocols and without changes 
	to SDP/RTSP	(this was disliked by others).
- Parsing. The blob is extracted and sent to the key management 
	function, which will accept/reject. MIKEY can also be a 
	standalone protocol, then it is binary encoded (exactly what 
	it is in MSEC). It may be transported in SIP/SDP and RTSP, 
	to reduce the setup time. Text-encoded means that we also 
	need for ex. to convert it into binary and let the 
	MIKEY module verify it. This conflicts with the goal of small 
	footprint implementation. This would also need one specific 
	solution for SDP and one different for RTSP.
- Small impact on the current SDP/RTSP implementation.

During an off-line discussion with the chairmen, we elaborated a 
solution that compromises between the approaches. The basic idea 
is to leave the blob approach, and to duplicate before it in the 
line the parameters needed to secure the media 
(e.g. authentication and encryption algorithms).
I.e. the line would now consists of two modules, one relevant to 
the media protection, the other only relevant to key management. 
The fact that we need to duplicate and cannot simply anticipate 
the attributes, is due to the fact that the authentication of the
key management needs strict position of (unchanged) fields. 
Having the security parameters only at the beginning of the line
and not inside the blob would mean the need of a parser to 
reconstruct the binary protocol so that the MIKEY implementation 
can verify it. 

Is the blob approch or the compromising approach (described above)
satisfying people?
We woud appreciate to hear the opinion of the group, as we would 
like to be able to have this issue solved. 

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 25 Oct 2002 16:05:00 +0300

Folks,

as far as I know, there were two concerns about this draft:

1) it uses binary encoding within a textual protocol (SDP).

2) since MIKEY is a protocol itself with its own state machine, the
draft should address how this state machine is linked to the SIP or RTSP
state machines.

About 1), the authors have proposed to use pure binary encoding for this
header or to use binary encoding anyway, but replicate some of the
information using textual format.

The draft addresses 2) with the following paragraphs:

Section 3.1. for SIP:

"If the offer is not accepted, the answerer SHOULD return a "606 Not
   Acceptable" message, including one or more Warning headers (at least
   a 306). The offerer MAY then go out with a new (different) offer,
   depending on the local security policy."

Section 3.3. for RTSP:
"If a server receives a
   SETUP message in which it expects a key management message, but none
   is included, a 403 Forbidden SHOULD be returned to the client."

Now, the WG should decide whether or not 1) and 2) have been properly
addressed. If they are, we should issue a WGLC. If not, the authors will
have to work on them with the comments from the group. In any event, we
will make progress.

What we cannot keep on doing is having this draft in the Limbo until the
authors get bored and give up. If there are still issues, let's resolve
them. If there are no issues, let's last-call it.

Thanks,

Gonzalo