Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-08.txt

From: "Fredrik Lindholm (KI/EAB)" <[email-masked]>
Date: Thu, 14 Aug 2003 18:08:15 +0200

Hi Colin,

and thanks for the comments.

> 
> I have a number of comments on this draft:
> 
>   - The ABNF in Sections 2.1 and 2.2 is contradictory. The key management
>     data is defined as "text" in one section, and "quoted-string" in the
>     other, yet these two types have different ranges of valid characters
>     (and both are more liberal than the explanatory text, which implies
>     that only base-64 encoded data is allowed). Similar for the protocol
>     identifier: the definitions of "non-ws-string" in SDPnew and "token"
>     in RTSP are not consistent.

This is as a result from the comments we received before, when we actually 
had consistent strings. At that time the comment was that we should use 
what was used in SDP and RTSP respectively (and the recommendations was 
to use non-ws-string and token). Please propose what to use.

>   - It should be stated that the protocol identifiers in Section 2.1 and
>     Section 2.2 refer to the same set of values, and a reference to the
>     registry of legal values should be given (i.e. reference the IANA
>     parameter registry defined in Section 6).

Ok.

> 
>   - The draft repeatedly mentions Kerberos, and indicates that Kerberos
>     tickets may be included in key management messages, but does not
>     specify how this is to be achieved. Should either specify how to use
>     Kerberos, or remove all references to it.

It was included as a result of a comment that we should give examples 
of more than one protocol that might utilize the framework. It is not 
our intention to specify how it can be used. We can agree that there are 
places where we could remove the reference. However, it might be good 
at least to keep the most general one in Section 3 to provide an overview
of the possibilities.  
 
>   - The second bullet point on Page 6 mentions that other parameters may
>     need to be specified for certain key management protocols, but does
>     not specify how an implementor knows if a particular key management
>     protocol uses additional parameters. Suggest this is listed as part
>     of the IANA registration for a particular key management protocol?

I don't see why IANA should handle this. However, it sounds reasonable 
that it should be documented in the key management draft (or a companion 
draft).
 
>   - Section 3.1 seems to assume Offer/Answer usage. It is not clear how
>     it applies to SDP used with, for example, SAP, HTTP, or email? What
>     about one-to-many distribution of SDP? Or distributions where there
>     is no back-channel? It is acceptable for the draft to be explicit
>     about the limits of its scope, but it cannot ignore the wider problem
>     space.

Ok, clarifications will be added. 
 
>   - The discussion of authentication on Page 7 is not mentioned in the
>     list of things senders and receivers of SDP must do, on pages 5 and
>     6.

Ok, we can mention it there as well.
 
>   - Section 3.3 does not mention authentication. Should I assume that
>     there is no need for authentication when key management is used with
>     RTSP?

Also in the RTSP case, the protocol name authentication described in 
section 3.1 should be applied. We will clarify this by explicitly 
state it. 
 
>   - Section 4 needs to provide strict guidance about the parameters and
>     specifications needed for new key management protocols. The interface
>     between the key management protocol and this framework should be made
>     explicit.

That is what we have tried to address. Please give examples of what
you think is lacking of that?

>   - I find the arguments about security of the SDP in Section 5 weak. The
>     draft needs to be explicit about the threats it prevents and those it
>     leaves open. Recommend re-reading RFC 3553, Section 5.

Ok.
 
>   - In section 5, how is a beat-down attack prevented when the attacker
>     wishes to beat-down to no security? What is the correct response to
>     an answer which suggests no security?

That would be to terminate/abort the session setup. 
 
>   - Section 6 needs to register the RTSP extensions needed, and make it
>     clear that the namespace for key management protocol identifiers is
>     shared between the RTSP and SDP extensions.

Ok.
 
>   - Section 6 mentions that new key management protocols specify "the
>     syntax of possible additional arguments", yet this contradicts the
>     ABNF which states that only a single argument is present.

Ok, that was a bad formulation. We'll fix that. 

> 
> The main issue behind these seems to be the desire to define new 
> parameters which can be left open for future uses. As was mentioned in 
> the context of the "a=gpmd:" attribute, this is not acceptable: there 
> needs to be a precise definition of the semantics of any new SDP 
> attribute/RTSP header before the draft can advance.

Ok, but doesn't fixing the above issues make this problem go away?

Fredrik

> -- 
> Colin Perkins
> http://csperkins.org/

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 28 Aug 2003 19:12:01 +0100

Hi,

On Thursday, Aug 14, 2003, at 17:08 Europe/London, Fredrik Lindholm 
(KI/EAB) wrote:
...
> to use non-ws-string and token). Please propose what to use.

If base-64 encoded text is a requirement, be explicit about that. 
Whatever is chosen, you will need to give an explicit ABNF definition, 
and include a comment stating that it is consistent with 
"non-ws-string" in the SDP section, and consistent with "token" in the 
RTSP section.

> at least to keep the most general one in Section 3 to provide an 

Including examples of other protocols which might use the framework in 
future is appropriate. The problem is that the draft states that 
Kerberos is supported ("Other protocols MAY use the described attribute 
and header, e.g. Kerberos"). It should say that the framework is 
intended to support other key management protocols, for example 
Kerberos, but that this is subject to future standardisation.

Be clear what is a possible future extension, and what is allowed today.

> that it should be documented in the key management draft (or a 

Each new key management protocol that uses this framework needs to 
provide this information. The way of ensuring this is to mandate that 
all new protocols that use the framework are registered with IANA, and 
that IANA require this information be provided.

> you think is lacking of that?

The draft asks for "the information the key management needs from SDP 
and RTSP", but doesn't indicate how that information is to be 
specified. For example, does one extract certain fields from the SDP? 
Is some information taken from an RTSP method or header? Does this data 
have to be put into a canonical form? etc. There needs to be almost a 
"checklist" the protocol designer and IANA can look at, to decide if 
the new protocol is completely specified.

> That would be to terminate/abort the session setup.

Okay, but that needs to be specified in the draft.

> Ok, but doesn't fixing the above issues make this problem go away?

Hopefully. The above issues were specific instances of a general 
problem with the draft.

-- 
Colin Perkins
http://csperkins.org/