Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-qos-identification-01

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 10 Oct 2008 14:44:01 +0300

Hi Tobias,

thanks for your review. I have revised the draft per your suggestions:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-qos-identification-02.txt

Cheers,

Gonzalo

Tobias Gondrom wrote:
> Hello,
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> Overall, the document is clear and ok. The only security review comment
> I have, is minor and regards text in the "Security Considerations"
> section.
> 
> Some additional non-security minor comments first:
> - COMMENT: Note: The document has expired in July 2008.
> - COMMENT: you should reconsider the reference section as it's using
> obsoleted normative references:
> (See RFCs 3967 and 4897 for information about using normative references
>      to lower-maturity documents in RFCs)
>   ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
>   ** Downref: Normative reference to an Informational RFC: RFC 4080
>   ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234)
> 
> - COMMENT:
> In Abstract:
> the first sentence is hadr to understand:
> „The offer/answer model for SDP assumes that endpoints establish,
>    somehow, the QoS required for the media streams they establish.“
>  maybe change to:
> „The offer/answer model for SDP assumes that endpoints establish somehow
> the QoS required for the media streams they establish.“
> Or reword this sentence for easier understanding?
> 
> 
> And finally in the Security Considerations:
> - COMMENT:
> The Security Considerations Section states correctly the risk of an
> attacker trying to add/remove/modify 'qos-mech-send' and/or
> 'qos-mech-recv' attributes from a session description.
> Protected sessions also SHOULD be authenticated (at least to the extend
> that the message sender is identical to the initial entity and not an
> attacker trying to inject a message with different QoS parameters.
> Usual integrity protection mechanisms (including the ones named as
> examples in the draft, e.g. S/MIME) also provide some authentication
> mechanisms and therefore usually fulfill this need, but this may not
> always be the case. Therefore the following sentence could be modified
> accordingly:
> old: „Consequently, it is strongly RECOMMENDED that integrity protection be
>    applied to SDP session descriptions carrying these attributes.“
> => new: "Consequently, it is strongly RECOMMENDED that integrity and
> authenticity protection be
>    applied to SDP session descriptions carrying these attributes."
> 
> Best regards,
> 
> Tobias
> 
> 

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir