This is in good shape - just a bunch of minor comments.
1. "The Real-time Transport Protocol (RTP) [RFC3550] is used
to transmit real time media on top of UDP and TCP [RFC4571].
Datagram TLS [RFC4347] was introduced to allow TLS functionality to
be applied to datagram transport protocols, such as UDP and DCCP.
This draft provides guidelines on how to establish SRTP [RFC3711]
security using an extension to DTLS (see [I-D.ietf-avt-dtls-srtp])."
This first says that RTP can be used on top of UDP and TCP, but then
says that this draft addresses the use of DTLS for establishing SRTP.
DTLS is applicable only when SRTP is carried over UDP, not TCP. This
should be made clear, e.g.,
"...guidelines on how to establish SRTP [RFC3711] security over UDP..."
^^^^^^^^
2. "S/MIME
signatures, as described in RFC 3261, or SIP Identity, as described
in [RFC4474] provides the highest level of security because they are
not susceptible to modification by malicious intermediaries."
Also there are other places in the draft that mention S/MIME, including
section 8.3. In the SIP session at IETF72 there was discussion about
deprecating S/MIME in SIP. If this is the intent of the WG, is it wise
to mention the technique in new RFCs?
3. "The SIP message
containing the offer SHOULD be sent to the offerer's sip proxy over
an integrity protected channel which SHOULD add an identity header
according to the procedures outlined in [RFC4474]. "
It is the proxy, not the channel, that should add the Identity header
field. Also some other nits. Change to:
"The endpoint SHOULD send the SIP message
containing the offer to the offerer's sip proxy over
an integrity protected channel. The proxy SHOULD add an Identity
header field
according to the procedures outlined in [RFC4474]."
4. "The far endpoint (answerer) may now establish a mutually
authenticated DTLS association to the offerer."
This assumes that the far endpoint will play the active role. However,
that is not necessarily so, and will depend what is negotiated in SDP.
5. "DTLS-SRTP does not provide anonymous calling."
Should this say:
"DTLS-SRTP does not prevent anonymous calling."?
^^^^^^^
6. "Additionally, it MUST be ensured that the Privacy header [RFC3325]
is
used in conjunction with the SIP identity mechanism to ensure that
the identity of the user is not asserted when enabling anonymous
calls."
In fact 3325 does not define the Privacy header field - it only defines
the additional value 'id'. Suggest we say:
"Additionally, it MUST be ensured that the Privacy header field with
value 'id' [RFC3325]...."
I don't know whether we also need a reference to RFC 3323, in which case
it would become:
"Additionally, it MUST be ensured that the Privacy header field
[RFC3323] with value 'id' [RFC3325]....".
7. Should section 6.1 on anonymous calls have an informative reference
to the ua-privacy draft?
8. "Each answerer will create a DTLS association with
the offerer."
It is not necessarily the case that the answerer will create the
association - it could also be the offerer.
9. "Once the answer is received, the active endpoint
will either reuse the existing association or establish a new one,
tearing down the existing association as soon as the offer/answer
exchange is completed."
If the answerer is the active endpoint, how can it determine that the
offer/answer exchange is completed, i.e., how does it know the offerer
has received the answer?
10. "Note
that this may mean adjusting the endpoint IP addresses if the
selected candidate pair shifts, just as if the DTLS packets were an
ordinary media stream."
What is the impact on the in-progress or completed DTLS handshake if
there is a shift of IP address?
11. "Implementations of this specification SHOULD support DTLS-SRTP
[I-D.ietf-avt-dtls-srtp]."
I thought the whole draft was about DTLS-SRTP. Therefore why is this
only SHOULD strength? Under what circumstances are exceptions allowed?
What are the alternatives to be used in these exceptional circumstances?
12. "Also note
that there is a fingerprint attribute on the 'c' line of the SDP."
An attribute is a separate line, not part of a c-line.
13. "This is computed from Bob's self-signed certificate."
That is true for the answer, but for the offer it is from Alice's
certificate.
14. "a=tcap:1 UDP/TLS/RTP/AVP RTP/AVP"
Shouldn't this be:
"a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP"
^
15. "Message 3 shows Bob
sending a DTLS ClientHello directly to Alice for each 'm' line in
the SDP. In this case two DTLS ClientHello messages are sent to
Alice. Bob sends a DTLS ClientHello to 192.168.1.103:6056 for RTP
and another to port 6057 for RTCP."
The figure does not show two ClientHello messages, but it should do.
This would then make the first sentence above wrong - it would be two
per 'm'line, not one per 'm' line. It is only one per 'm' line if
RTP/RTCP mux is used.
16. "Note that in this case, Bob signals the actual transport protocol
configuration of SRTP over DTLS in the acfg parameter."
This appears under message 9 (RTP/RTCP), but really it should occur
under message 8 (200 OK).
17. "When phone number URIs (e.g.,
'sip:[EMAIL PROTECTED]') are used, there is no
structural reason to trust that the domain name is authoritative
for a given phone number, although individual proxies and UAs may
have private arrangements that allow them to trust other domains."
This might suggest that the problem exists only when user=phone is
absent, whereas it exists also (more particularly so) when user=phone is
present. It might be better to say:
"When phone number URIs (e.g.,
'sip:[EMAIL PROTECTED]' or
'sip:[EMAIL PROTECTED];user=phone') are used...."
NITS:
- Change "media plan" to "media plane".
- "in Enhancements for Authenticated Identity
Management in SIP [RFC4474] is used" - delete "in".
- "SIP proxies downstream of the identity service" change to "SIP
proxies downstream of the authentication service"
- "Since the identity header is a
digital signature across several SIP headers, in addition to the
bodies of the SIP message, "
This contains several instances of wrong terminology. "identity header"
should be "Identity header field. "SIP headers" should be "SIP header
fields", and "bodies" should be "body". A SIP message has a single
header (comprising header fields) and a single body (perhaps containing
multiple body parts). Similar corrections are needed throughout the
document.
- "upon receiving the other side's then"
I think this should say:
"upon receiving the other side's SDP then"
^^^
- "and key negotiation succeeds otherwise RTP is used"
Change to:
"and key negotiation succeeds, otherwise RTP is used"
^
- "RTP is the
default and will be understood by endpoints that do not understand
SRTP or this key exchange mechanism but SRTP is preferred."
Change to:
"This allows an offerer to express a preference for SRTP, but RTP is the
default and will be understood by endpoints that do not understand
SRTP or this key exchange mechanism."
- "Answerers SHOULD use this UPDATE mechanisms."
Change "mechanisms" to "mechanism".
- "the assurances of DTLS-SRTP provides "
Change to:
"the assurances that DTLS-SRTP provides"
^^^^
John
_______________________________________________
Sip mailing list https://www.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
