> -----Original Message-----
> From: Richard Barnes [mailto:[EMAIL PROTECTED]
> Sent: Saturday, October 06, 2007 3:24 PM
> To: IETF SIP List; 'Dan Wing'; Hannes Tschofenig; Fries,
> Steffen; Francois Audet
> Subject: Review of draft-ietf-sip-media-security-requirements-00
>
> High-level comments are in the body of this message. More detailed
> comments in the attached RTF file.
Thanks, and please accept my apologies for my delay.
I believe the only outstanding issues are around requirements R23-R25;
see below for details.
> --Richard
>
> -------------------------------------------------------
> Document: draft-ietf-sip-media-security-requirements-00
> Reviewer: Richard Barnes, BBN
> Review Date: 06 September 2007
> -------------------------------------------------------
>
> 1. As a document proposing requirements for a security protocol,
> this document needs more discussion of the system being protected
> and the level of protection that the desired protocol is to
> support. Section 5 is a good start on this, and it should be
> moved forward to be just after the Terminology section.
I have moved this section in -01.
> 2. I think the fundamental security requirement that you're driving
> at is that the protocol should have a mode of operation in which
> an attacker must mount active attacks on BOTH the signaling and
> media path in order to gain access to the keys being negotiated
> by the protocol, and that even in this case, the attack should be
> detectable by the endpoints. This is essentially what's being
> encoded in requirements R1, R2, and R17, but this should be made
> clearer in these requirements, and in the security analysis
> section (i.e., Section 5).
R17 in -00 said:
The media security key management protocol SHOULD require
the adversary to have access to the data as well as the
signaling path for a successful attack to be launched. An
adversary that is located only along the data or only along
the signaling path MUST NOT be able to successfully mount
an attack. A successful attack refers to the ability for
the adversary to obtain keying material to decrypt the SRTP
encrypted media traffic.
which I think is sufficiently clear on this point. Let me know if
you still feel it should be repeated elsewhere.
> 3. Requirements R23, R24, R25 are inappropriate for this document,
> in that they conflict directly with the security requirements
> (R1, R2, R17). A well-designed key-exchange protocol *should* be
> able to detect a middle-man, authorized or not. Lawful intercept
> should be handled outside of the key management protocol, as in
> draft-wing-sipping-srtp-key.
For reference in this response, R23, R24, and R25 are:
R23: The media security key management protocol SHOULD support
recording of decrypted media.
Media recording may be realized by an intermediate nodes. An
example for those intermediate nodes are devices, which could
be used in banking applications or for quality monitoring in
call centers. Here, it must be ensured, that the media
security is ensured by the intermediate nodes on the
connections to the involved endpoints as originally
negotiated. The endpoints need to be informed that there is
an intermediate device and need to cooperate. A solution
approach for this is described in [I-D.wing-sipping-srtp-key].
R23 refers only to recording of media. This is necessary in many
business environments such as banks, stock brokers, catalog ordering call
centers, and so on. This is a requirement for many businesses. It
is not yet clear if draft-wing-sipping-srtp-key (or something like it)
meets requirement R23.
R24: The media security key management protocol SHOULD NOT allow
end users to determine whether their end-to-end interaction is
subject to lawful interception.
I agree R24 refers to lawful intercept. This is a requirement from
other SDOs that need to provide lawful intercept with their solutions.
Another email on R24 lawful intercept will be forthcoming shortly.
R25: The media security key management protocol MUST work when
there are intermediate nodes, terminating or processing media,
between the end points."
R25 reference to 'intermediate nodes' is to transcoders and SBCs which
handle signaling and media traffic. It seems important that any keying
mechanism work with such intermediate nodes, as those intermediate nodes
are common on many SIP networks.
> 4. This document needs several more terms defined in the
> Terminology. The three I spotted were: "media path", "signaling
> path", and "perfect forward secrecy". PFS is already defined in
> the requirements; this text should just be moved to the
> Terminology section.
Added to -01, thanks.
> 5. If we intend this document to move quickly toward RFC status, it
> seems like the evaluation appendices will have to be deleted, or
> at least the parts of them that refer to protocols that are not
> RFCs or not on their way.
This evaluation captures the protocols under consideration at the
time that this evaluation occurred. It is valuable to describe why
some protocols were not selected. If there are specific protocols
you'd like deleted, please enumerate them; each seems to have its
place (although I do agree several are minor tweaks on other
protocols).
> 6. Section 3.1 and 3.3 do not appear to be directly related to the
> requirements as stated. They should be moved to sections B.2 and
> B.3, respectively (like the text on SSRCs and ROCs).
Section 3.1 is "Clipping Media Before Signaling Answer" and
refers to requirement R5:
R5: The media security key management protocol SHOULD avoid
clipping media before SDP answer without requiring PRACK
[RFC3262].
Section 3.2 is "Retargeting and Forking" and refers to requirements
R1, R2, and R3:
R1: The media security key management protocol MUST support
forking and retargeting when all endpoints are willing to use
SRTP without causing the call setup to fail, unless the
execution of the authentication and key exchange protocol
leads to a failure (e.g., an unsuccessful authentication
attempt).
R2: Even when some end points of a forked or retargeted call are
incapable of using SRTP, the key management protocol MUST
allow the establishment of SRTP associations with SRTP-capable
endpoints and / or RTP associations with non-SRTP-capable
endpoints.
R3: The media security key management protocol MUST create
distinct, independent cryptographic contexts for each endpoint
in a forked session.
In -01, I have added text to the beginning of 3.1 and 3.2 to make this
clearer.
> 7. Sections C.1 and C.3 should be deleted. Section C.1. is
> predicated on the notion that protocols require a PKI to be used,
> when in reality (as was discussed extensively on rtpsec), any
> protocol that can be used with a PKI can be used with self-signed
> certificates if both endpoints are willing. Section C.3. tries
> to evaluate whether solutions can do best-effort security, while
> ignoring the work that has been done on SDP capability
> negotiation.
Section C.3 ("Best Effort Encryption") has been updated to
discuss SDP Capability Negotiation; previously it only said:
"Note: With the ongoing efforts in SDP Capability Negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation], the conclusions
reached in this section may no longer be accurate."
which I agree was deficient.
> *. (nit) Throughout, the word "keying" is used to mean the process of
> key negotiation/exchange or key management. It should be replaced by
> those terms as appropriate.
Changed in -01.
Thanks to Steffen for making a significant number of these changes to
the XML.
-d
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
