[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] WGLC comments on draft-ietf-sip-dtls-srtp-framework-02
A few random comments:
The fingerprint alone protects against active attacks on the media
but not active attacks on the signalling. In order to prevent active
attacks on the signalling, in Enhancements for Authenticated Identity
Management in SIP [RFC4474] is used.
I believe we should indicate that SIP Identity >>may<< be used.
When Bob receives the offer,
Bob establishes a mutually authenticated DTLS connection with Alice.
It is not really mutually authenticated at this point in time.
Something like
"
When Bob receives the offer,
Bob initiates a DTLS exchange with Alice.
"
At this point Bob can begin sending media to Alice. Once Bob accepts
Alice's offer and sends an SDP answer to AlicFrom sip-bounces at ietf.org Mon Aug 11 09:13:23 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id A120F3A6C7F;
Mon, 11 Aug 2008 09:13:23 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 657753A6C7F
for <sip at core3.amsl.com>; Mon, 11 Aug 2008 09:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.554
X-Spam-Level:
X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5
tests=[AWL=-0.555, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id y9dxBiLoIBID for <sip at core3.amsl.com>;
Mon, 11 Aug 2008 09:13:20 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net
[217.115.75.234])
by core3.amsl.com (Postfix) with ESMTP id 0C3363A6AF0
for <SIP at ietf.org>; Mon, 11 Aug 2008 09:13:19 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55])
by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id
m7BGDKsE027030
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <SIP at ietf.org>; Mon, 11 Aug 2008 18:13:20 +0200
Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36])
by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP
id m7BGDKmV028938 for <SIP at ietf.org>; Mon, 11 Aug 2008 18:13:20 +0200
Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by
demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);
Mon, 11 Aug 2008 18:13:20 +0200
Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by
demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);
Mon, 11 Aug 2008 18:13:19 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 11 Aug 2008 19:12:03 +0300
Message-ID: <C41BFCED3C088E40A8510B57B165C1624B03C9 at FIESEXC007.nsn-intra.net>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0F8D412 at GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: WGLC comments on draft-ietf-sip-dtls-srtp-framework-02
Thread-Index: Acj5eOdUgdqYw3W1QqOmsc5MdWk4JgCU7TYg
References: <0D5F89FAC29E2C41B98A6A762007F5D0F8D412 at GBNTHT12009MSX.gb002.siemens.net>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig at nsn.com>
To: "SIP IETF" <SIP at ietf.org>
X-OriginalArrivalTime: 11 Aug 2008 16:13:19.0140 (UTC)
FILETIME=[2B2E9640:01C8FBCD]
Subject: [Sip] WGLC comments on draft-ietf-sip-dtls-srtp-framework-02
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
A few random comments:
The fingerprint alone protects against active attacks on the media
but not active attacks on the signalling. In order to prevent active
attacks on the signalling, in Enhancements for Authenticated Identity
Management in SIP [RFC4474] is used.
I believe we should indicate that SIP Identity >>may<< be used.
When Bob receives the offer,
Bob establishes a mutually authenticated DTLS connection with Alice.
It is not really mutually authenticated at this point in time.
Something like
"
When Bob receives the offer,
Bob initiates a DTLS exchange with Alice.
"
At this point Bob can begin sending media to Alice. Once Bob accepts
Alice's offer and sends an SDP answer to Alice, Alicee, Alice can begin
sending confidential media to Bob.
We would have to assume symmetric RTP (which is only recommended by
draft-ietf-avt-dtls-srtp) here to allow Alice to send media immediately
after the DTLS handshake. Otherwise we may need another DTLS handshake
before Alice can send media to Bob.
I was actually wondering why not to mandate symmetric RTP given that the
number of exchanges are much lower.
Alice and Bob will verify the
fingerprints from the certificates received over the DTLS handshakes
match with the fingerprints received in the SDP of the SIP signaling.
This provides the security property that Alice knows that the media
traffic is going to Bob and vice-versa without necessarily requiring
global PKI certificates for Alice and Bob.
o When RFC 4474 Identity is used, this solution works even when the
SIP proxies downstream of the identity service are not trusted.
We could provide a pointer to the security considerations section,
namely Section 8.6.
A pointer to RFC 4916 ("Connected Identity"), even though I do not
consider it as too important based on the scenarios it addresses, would
not hurt here.
Maybe something like would help:
"Retargeting of a dialog-forming request (changing the value of the
Request-URI), the UA that receives
it (the User Agent Server, UAS) can have a different identity from
that in the To header field. When RFC 4916 is used then it is
possible to supply its identity to the peer UA by means of a request in
the
reverse direction, and for that identity to be signed by an
Authentication Service.
"
There is no need to reveal keys in the SIP signaling or in the SDP
message exchange. In order for SDES and MIKEY to provide this
security property, they require distribution of certificates to
the endpoints that are signed by well known certificate
authorities.
I believe we should delete the last sentence since we provide a detailed
discussion of SDES and MIKEY in the media security requirements
document.
Section 5
The far endpoint (answerer) may now establish a mutually
authenticated DTLS association to the offerer.
The same comment from above applies since at this stage there two end
points aren't mutually authenticated yet.
o If the fingerprint does not match the hashed certificate then the
endpoint MUST tear down the media session immediately.
Tentatively establishing a session and tearing it down if the
fingerprint doesn't match is one possible strategy. Alternatively, the
offerer could wait for an answer with the fingerprint and subsequently
execute the DTLS handshake and cancel the handshake and the session
establishment immediately if the cert used in the handshake does not
match the fingerprint.
This would obviously delay the establishment of the secure channel.
Particularly for early media this would mean that media is unprotected.
Early media will, however, be tough anyway.
I don't have a strong opinion on the two approaches but I believe we
should mention the DoS potential in the security consideration section.
6.5. Session Modification
Once an answer is provided to the offerer, either endpoint MAY
request a session modification which MAY include an updated offer.
This session modification can be carried in either an INVITE or
UPDATE request. 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.
I think we need to differentiate the case where the SDP changes only
slightly, for example, a change in codec vs. the case where, for
example, an IP address changes.
Hence, in some cases creating a new association might not even be
possible.
Section 7:
The SIP signaling from Alice to her proxy is transported over TLS to
ensure an integrity protected channel between Alice and her identity
service. Note that all other signaling is transported over TCP in
this example although it c can begin
sending confidential media to Bob.
We would have to assume symmetric RTP (which is only recommended by
draft-ietf-avt-dtls-srtp) here to allow Alice to send media immediately
after the DTLS handshake. Otherwise we may need another DTLS handshake
before Alice can send media to Bob.
I was actually wondering why not to mandate symmetric RTP given that the
number of exchanges are much lower.
Alice and Bob will verify the
fingerprints from the certificates received over the DTLS handshakes
match with the fingerprints received in the SDP of the SIP signaling.
This provides the security property that Alice knows that the media
traffic is going to Bob and vice-versa without necessarily requiring
global PKI certificates for Alice and Bob.
o When RFC 4474 Identity is used, this solution works even when the
SIP proxies downstream of the identity service are not trusted.
We could provide a pointer to the security considerations section,
namely Section 8.6.
A pointer to RFC 4916 ("Connected Identity"), even though I do not
consider it as too important based on the scenarios it addresses, would
not hurt here.
Maybe something like would help:
"Retargeting of a dialog-forming request (changing the value of the
Request-URI), the UA that receives
it (the User Agent Server, UAS) can have a different identity from
that in the To header field. When RFC 4916 is used then it is
possible to supply its identity to the peer UA by means of a request in
the
reverse direction, and for that identity to be signed by an
Authentication Service.
"
There is no need to reveal keys in the SIP signaling or in the SDP
message exchange. In order for SDES and MIKEY to provide this
security property, they require distribution of certificates to
the endpoints that are signed by well known certificate
authorities.
I believe we should delete the last sentence since we provide a detailed
discussion of SDES and MIKEY in the media security requirements
document.
Section 5
The far endpoint (answerer) may now establish a mutually
authenticated DTLS association to the offerer.
The same comment from above applies since at this stage there two end
points aren't mutually authenticated yet.
o If the fingerprint does not match the hashed certificate then the
endpoint MUST tear down the media session immediately.
Tentatively establishing a session and tearing it down if the
fingerprint doesn't match is one possible strategy. Alternatively, the
offerer could wait for an answer with the fingerprint and subsequently
execute the DTLS handshake and cancel the handshake and the session
establishment immediately if the cert used in the handshake does not
match the fingerprint.
This would obviously delay the establishment of the secure channel.
Particularly for early media this would mean that media is unprotected.
Early media will, however, be tough anyway.
I don't have a strong opinion on the two approaches but I believe we
should mention the DoS potential in the security consideration section.
6.5. Session Modification
Once an answer is provided to the offerer, either endpoint MAY
request a session modification which MAY include an updated offer.
This session modification can be carried in either an INVITE or
UPDATE request. 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.
I think we need to differentiate the case where the SDP changes only
slightly, for example, a change in codec vs. the case where, for
example, an IP address changes.
Hence, in some cases creating a new association might not even be
possible.
Section 7:
The SIP signaling from Alice to her proxy is transported over TLS to
ensure an integrity protected channel between Alice and her identity
service. Note that all other signaling is transported over TCP in
this example although it could be ould be done over any supported transport.
I guess we should also say that the communication between the SIP
proxies is protected someone, specifically when SIP Identity (or other
security mechanisms) is not available.
This shows the initial INVITE from Alice to Bob carried over the
TLS transport protocol to ensure an integrity protected channel
between Alice and her proxy which acts as Alice's identity
service. Note that Alice has requested to be either the active or
passive endpoint by specifying a=setup:actpass. Bob chooses to
act as the DTLS server and will initiate the session. Also note
that there is a fingerprint attribute on the 'c' line of the SDP.
This is computed from Bob's self-signed certificate.
Shouldn't this be Alice's self-signed cert, as shown in the subsequent
exchange.
At this point, Bob can begin sending early media (RTP and RTCP) to
Alice. Note that Alice can't yet trust the media since the
fingerprint has not yet been received. This lack of trusted,
secure media is indicated to Alice.
At the last sentence we should indicate that this indication is part of
the user interface rather than something that is meant to be part of the
protocol exchange.
Section 8: Security Considerations
Other mechanisms, such as the S/MIME mechanism described
in RFC 3261, or the mechanisms described in
[I-D.wing-sip-identity-media] or [I-D.fischer-sip-e2e-sec-media],
could also serve this purpose.
I believe we should just mention S/MIME and SIP CERT rather than
individual drafts that may not go anywhere.
Section 8.2:
This sentence is a bit tough to read:
If SIP Identity is not used, but the signaling is protected by SIPS,
the security guarantees are weaker, but some security is still
provided as long as all proxies are trusted, this provides integrity
for the fingerprint.
Suggest to break it into 3 sentences:
If SIP Identity is not used, but the signaling is protected by SIPS,
the security guarantees are weaker. Some security is still
provided as long as all proxies are trusted. This provides integrity
for the fingerprint in a chain-of-trust security model.
It does not provide a strong assertion of who
Alice is communicating with. However, as much as the target domain
can be trusted to correctly populate the From header field value,
Alice can use that. The security issue with this approach is that if
one of the Proxies wished to mount a man-in-the-middle attack, it
could convince Alice that she was talking to Bob when really the
media was flowing through a man in the middle media relay. However,
this attack could not convince Bob that he was taking to Alice.
I believe that this last paragraph does not provide a lot of value given
that SIPS fits into the chain of trust security model and hence, by
definition, you have to trust the proxies. If the proxies are, for some
reason, not trustworthy anymore than there is a problem.
8.3. S/MIME
I would delete the last sentence from that section, namely
"
However, so far there have been no deployments of S/MIME
for SIP.
"
Reason: The problem is not really S/MIME as such. The problem is how to
distribute the certificates. This problem has, however, been tackeled
with SIP CERT and hence the situation may look different in a few years.
Additionally, one could argue of lack of deployment of other security
mechanisms as well.
8.5. Short Authentication String
DTLS does not natively support
this mode, however it would be straightforward to add one as a TLS
extension [RFC3546].
I would delete the term "straightforward" and say something like
"
DTLS does not natively support
this mode. Based on the level of deployment interest a TLS
extension [RFC3546] could provide support for it.
"
Reason: There has not been a lot of interest in this mechanism lately.
Hence, I am not sure whether there is actually a lot interest from the
community.
Additionally, it might be useful to indicate that this mechanism odone over any supported transport.
I guess we should also say that the communication between the SIP
proxies is protected someone, specifically when SIP Identity (or other
security mechanisms) is not available.
This shows the initial INVITE from Alice to Bob carried over the
TLS transport protocol to ensure an integrity protected channel
between Alice and her proxy which acts as Alice's identity
service. Note that Alice has requested to be either the active or
passive endpoint by specifying a=setup:actpass. Bob chooses to
act as the DTLS server and will initiate the session. Also note
that there is a fingerprint attribute on the 'c' line of the SDP.
This is computed from Bob's self-signed certificate.
Shouldn't this be Alice's self-signed cert, as shown in the subsequent
exchange.
At this point, Bob can begin sending early media (RTP and RTCP) to
Alice. Note that Alice can't yet trust the media since the
fingerprint has not yet been received. This lack of trusted,
secure media is indicated to Alice.
At the last sentence we should indicate that this indication is part of
the user interface rather than something that is meant to be part of the
protocol exchange.
Section 8: Security Considerations
Other mechanisms, such as the S/MIME mechanism described
in RFC 3261, or the mechanisms described in
[I-D.wing-sip-identity-media] or [I-D.fischer-sip-e2e-sec-media],
could also serve this purpose.
I believe we should just mention S/MIME and SIP CERT rather than
individual drafts that may not go anywhere.
Section 8.2:
This sentence is a bit tough to read:
If SIP Identity is not used, but the signaling is protected by SIPS,
the security guarantees are weaker, but some security is still
provided as long as all proxies are trusted, this provides integrity
for the fingerprint.
Suggest to break it into 3 sentences:
If SIP Identity is not used, but the signaling is protected by SIPS,
the security guarantees are weaker. Some security is still
provided as long as all proxies are trusted. This provides integrity
for the fingerprint in a chain-of-trust security model.
It does not provide a strong assertion of who
Alice is communicating with. However, as much as the target domain
can be trusted to correctly populate the From header field value,
Alice can use that. The security issue with this approach is that if
one of the Proxies wished to mount a man-in-the-middle attack, it
could convince Alice that she was talking to Bob when really the
media was flowing through a man in the middle media relay. However,
this attack could not convince Bob that he was taking to Alice.
I believe that this last paragraph does not provide a lot of value given
that SIPS fits into the chain of trust security model and hence, by
definition, you have to trust the proxies. If the proxies are, for some
reason, not trustworthy anymore than there is a problem.
8.3. S/MIME
I would delete the last sentence from that section, namely
"
However, so far there have been no deployments of S/MIME
for SIP.
"
Reason: The problem is not really S/MIME as such. The problem is how to
distribute the certificates. This problem has, however, been tackeled
with SIP CERT and hence the situation may look different in a few years.
Additionally, one could argue of lack of deployment of other security
mechanisms as well.
8.5. Short Authentication String
DTLS does not natively support
this mode, however it would be straightforward to add one as a TLS
extension [RFC3546].
I would delete the term "straightforward" and say something like
"
DTLS does not natively support
this mode. Based on the level of deployment interest a TLS
extension [RFC3546] could provide support for it.
"
Reason: There has not been a lot of interest in this mechanism lately.
Hence, I am not sure whether there is actually a lot interest from the
community.
Additionally, it might be useful to indicate that this mechanism only
helpnly
helps when you actually know the person's voice. This fits to some
communication patters. When you know your communication partners already
out-of-band then things are a lot easier anyway.
For those cases where this is not true things get more complicated. For
example, how do I know that I talk to a person at my bank, insurance
company, car dealer, travel agency, help desk, etc.? One may not know
the voice of these folks.
Appendix A:
A.4. Clipping (R-AVOID-CLIPPING)
Because the key establishment occurs in the media plane, media need
not be clipped before the receipt of the SDP answer.
I believe we should indicate that in this case the early media is not
secured.
A.7. (R-SIG-MEDIA, R-ACT-ACT)
It might be good to indicate that the interaction between the UA and the
authentication service needs to be secured as well and that the
authentication service is responsible for executing proper
authentication of the user.
A.8. Binding to Identifiers (R-ID-BINDING)
We should weaken the language a bit to indicate that other mechanisms,
such as SIP CERT and S/MIME may also be used and not only SIP Identity.
A.11. RTP Validity Check (R-RTP-VALID)
We should also mention STUN packets by referencing Section 5.1.2 of
http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-03
A.15. Denial of Service Vulnerability (R-DOS)
DTLS offers some degree of DoS protection particuarly as a built-in
feature.
A.16 is already covered by A.7. I would delete it.
A.18: Maybe we should add one more sentence: "RFC 4474 is able to
prevent an active attacker on the signalling path to downgrade the call
from SRTP to RTP."
A.22. Interworking with Intermediaries (R-TRANSCODER)
"
A description of the interworking with Session Border Controllers is
described in this document.
"
The interworking with SBCs is covered in
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-path-middleb
oxes-01.txt
However, as the text of interworking is written in
http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requir
ements-07.txt
the transcoder needs to have access to the keying material and therefore
the description from A.21 on media recording (and key disclosure) is
applicable here as well.
A.23. PSTN Gateway Termination (R-PSTN)
The DTLS-SRTP framework allows the media security to terminate at a
PSTN gateway. This does not provide end-to-end security, but is
consistent with the security goals of this framework because the
gateway is authorized to speak for the PSTN namespace.
There are several scenarios that would have to be discussed in this
context; they are described in Section 3 of
draft-schwartz-sip-e164-ownership-01.txt, namely
* IP-IP Case (not relevant to Section A.23 although E.164 numbers are
used).
* IP-PSTN-IP Case
* PSTN-to-IP Case
* IP-to-PSTN Case
The problems are slightly different for each of these cases. However, as
most folks would probably agree the security of all these cases is
rather weak (or at least unpredictable).
I wonder how to best treat this subject but it may not hurt to describe
the issues in more detail in the appendix. Text is already available --
hence it would be more of a copy-and-paste operation.
There are two requirements that have not been discussed: R-ALLOW-RTP and
R-HERFP.
"R-ALLOW-RTP: DTLS-SRTP allows RTP media to be received by the calling
party until SRTP has been negotiated with the answerer, after which SRTP
is preferred over RTP.
"
Here is first try:
"
R-HERFP: The Heterogeneous Error Response Forking Problem (HERFP) is not
applicable to DTLS-SRTP since the key exchange protocol will be executed
along the media path and hence error messages are communicated along
this path and proxies do not need to progress them.
"
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
s when you actually know the person's voice. This fits to some
communication patters. When you know your communication partners already
out-of-band then things are a lot easier anyway.
For those cases where this is not true things get more complicated. For
example, how do I know that I talk to a person at my bank, insurance
company, car dealer, travel agency, help desk, etc.? One may not know
the voice of these folks.
Appendix A:
A.4. Clipping (R-AVOID-CLIPPING)
Because the key establishment occurs in the media plane, media need
not be clipped before the receipt of the SDP answer.
I believe we should indicate that in this case the early media is not
secured.
A.7. (R-SIG-MEDIA, R-ACT-ACT)
It might be good to indicate that the interaction between the UA and the
authentication service needs to be secured as well and that the
authentication service is responsible for executing proper
authentication of the user.
A.8. Binding to Identifiers (R-ID-BINDING)
We should weaken the language a bit to indicate that other mechanisms,
such as SIP CERT and S/MIME may also be used and not only SIP Identity.
A.11. RTP Validity Check (R-RTP-VALID)
We should also mention STUN packets by referencing Section 5.1.2 of
http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-03
A.15. Denial of Service Vulnerability (R-DOS)
DTLS offers some degree of DoS protection particuarly as a built-in
feature.
A.16 is already covered by A.7. I would delete it.
A.18: Maybe we should add one more sentence: "RFC 4474 is able to
prevent an active attacker on the signalling path to downgrade the call
from SRTP to RTP."
A.22. Interworking with Intermediaries (R-TRANSCODER)
"
A description of the interworking with Session Border Controllers is
described in this document.
"
The interworking with SBCs is covered in
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-path-middleb
oxes-01.txt
However, as the text of interworking is written in
http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requir
ements-07.txt
the transcoder needs to have access to the keying material and therefore
the description from A.21 on media recording (and key disclosure) is
applicable here as well.
A.23. PSTN Gateway Termination (R-PSTN)
The DTLS-SRTP framework allows the media security to terminate at a
PSTN gateway. This does not provide end-to-end security, but is
consistent with the security goals of this framework because the
gateway is authorized to speak for the PSTN namespace.
There are several scenarios that would have to be discussed in this
context; they are described in Section 3 of
draft-schwartz-sip-e164-ownership-01.txt, namely
* IP-IP Case (not relevant to Section A.23 although E.164 numbers are
used).
* IP-PSTN-IP Case
* PSTN-to-IP Case
* IP-to-PSTN Case
The problems are slightly different for each of these cases. However, as
most folks would probably agree the security of all these cases is
rather weak (or at least unpredictable).
I wonder how to best treat this subject but it may not hurt to describe
the issues in more detail in the appendix. Text is already available --
hence it would be more of a copy-and-paste operation.
There are two requirements that have not been discussed: R-ALLOW-RTP and
R-HERFP.
"R-ALLOW-RTP: DTLS-SRTP allows RTP media to be received by the calling
party until SRTP has been negotiated with the answerer, after which SRTP
is preferred over RTP.
"
Here is first try:
"
R-HERFP: The Heterogeneous Error Response Forking Problem (HERFP) is not
applicable to DTLS-SRTP since the key exchange protocol will be executed
along the media path and hence error messages are communicated along
this path and proxies do not need to progress them.
"
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip