> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean
Willis
> Sent: Wednesday, July 23, 2008 1:26 AM
> To: SIP IETF
> Cc: Cullen Jennings
> Subject: [Sip] WGLC on DTLS Framework draft-ietf-sip-dtls-srtp-framework-02
>
>
> I'm happy to announce a Working Group Last Call on the
> standards-track DTLS Framework document:
>
>
http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-02.txt
>
> I'd like to conclude this WGLC by Friday, August 8, 2008.
>
> Please review the document and send any comments to the list and
> author Eric Rescorla.
I'm happy to see this finally WGLC'd, too!
Overall:
The framework document needs to require endpoints send and
receive ietf-mmusic-sdp-capability-negotiation. Without support
for that draft, many of the media security requirements cannot be
met (as mentioned in A.1 of draft-ietf-sip-dtls-srtp-framework-02).
ietf-mmusic-sdp-capability-negotiation should be promoted
to a normative requirement, and should be required (MUST) for
endpoints to support in order to adhere to the DTLS-SRTP framework.
Otherwise, we are hosed for forking and hosed for retargeting.
Section 1, Introduction:
However, even hop-by-hop security such as provided by SIPS provides
some protection against modification by attackers who are not on the
signalling path.
With or without SIPS, if the attacker is off the signalling path, the
attacker has little hope of doing much damage -- they need to
guess a lot of SDP values and guess a bunch of SIP values (call-id)
in order to be successful.
So, I would replace the last phrase with:
"... who are not in control of on-path signaling elements."
resulting in:
However, even hop-by-hop security such as provided by SIPS provides
some protection against modification by attackers who are not in
control of on-path signaling elements."
Section 5, Exchanging Certificates:
(the text exceeds the section title when it goes beyond just what
happens with certificate exchange; perhaps consider re-titling).
My slightly more substantive comment is:
The answerer SHOULD use the setup attribute value of
setup:active and will send the client_hello in the media path."
^^^^
MUST
Section 6.6, "ICE Interaction":
...
If ICE is not being used, then there is potential for a bad
interaction with SBCs via "latching", as described in
[I-D.ietf-mmusic-media-path-middleboxes]. In order to avoid this
issue, if ICE is not being used and the DTLS handshake has not
completed, upon receiving the other side's then the passive side MUST
^
SDP
do a single unauthenticated STUN [I-D.ietf-behave-rfc3489bis]
connectivity check in order to open up the appropriate pinhole.
Requirements to do something when ICE is *not* being used should not be in a
section titled "ICE Interaction". I would move this paragraph describing how
to handle SBC 'latching' to its own section perhaps titled "SBC Interaction".
Section 8.6,
o When phone number URIs (e.g.,
'sip:[EMAIL PROTECTED]') are used,
I believe the current consensus is that a phone number would include
;user=phone, so the example should be
sip:[EMAIL PROTECTED];user=phone
Section 8.6, "Limits of Identity Assertions"
(This section is well written.)
Implementors should therefore take care not to indicate
misleading peer identity information in the user interface. e.g. If
^^^^^^
formatting error around here
the peer's identity is sip:[EMAIL PROTECTED], it is
not sufficient to display that the identity of the peer as
+17005551008, unless there is some policy that states that the domain
"chicago.example.com" is trusted to assert E.164 numbers.
chicago.example.com only needs to be trusted to assert numbers you trust
it to assert -- not a blanked "to assert E.164 numbers". For example,
I might trust, and expect, Verizon to claim E.164s that it owns, but
I do not trust, nor expect, Verizon to claim an E.164 with a +353
country code.
I would revise the above to end with something like:
... unless there is some policy that states that the domain
"chicago.example.com" is trusted to assert the E.164 number
is it asserting.
^^^^^^^^^^^^^^^
later,
Otherwise, the recipient cannot rely on the RFC 4474 Identity
assertion and the UA MUST not indicate to the user that a secure call
^^^^^^^^
MUST NOT
has been established to the claimed identity. Implementations which
are configured to only establish secure calls SHOULD terminate the
call in this case.
Section A.3:
add a reference to draft-ietf-avt-dtls-srtp-03.txt
which describes how session resumption is supposed to be
implemented.
Section A.12., "3rd Party Certificates (R-CERTS, R-EXISTING)"
Third party certificates are not required. However, if the parties
share an authentication infrastructure that is compatible with TLS
(3rd party certificates or shared keys) it can be used.
RFC4474 is part of the framework for securing DTLS-SRTP, and
as you know there is a lot of consternation around this point.
Citing section 13.4 of RFC4474 would be helpful, because section
A.12 of sip-dtls-srtp-framework relies on the following small
sentence in Section 13.4 of RFC4474:
It
is strongly RECOMMENDED that self-signed domain certificates should
not be trusted by verifiers, unless some previous key exchange has
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
justified such trust.
^^^^^^^^^^^^^^^^^^^^
Section A.15, Denial of Service Vulnerability (R-DOS)
Please add a reference to Section 4.2.1 of RFC4347.
Section A.18., "Downgrading Protection (R-DOWNGRADE)"
DTLS provides protection against downgrading attacks since the
selection of the offered ciphersuites is confirmed in a later stage
of the handshake. This protection is efficient unless an adversary
is able to break a ciphersuite in real-time.
This should also mention integrity protection of signaling is
necessary in order to prevent downgrade to RTP (because I believe
we need to require sdp-capability-negotiation for all of this to
work correctly.)
-d
_______________________________________________
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
