Re: [AVTCORE] Review of draft-ietf-avtcore-rtp-security-options-01

[Magnus Westerlund <[e-mail]>]

Hi Christian,

Sorry for being so late in responding to your email with comments. They
are very good comments and we are making a number of changes to the
draft to address these. A new version should be available soon.

See inline for the proposals when suitable. I would appreciate feedback
on the proposed changes.

The last issue has an open question which I require WG input on.



On 2012-12-12 13:59, Correll, Christian wrote:
> Hi,
>  
> I reviewed the RTP security options document and I have following comments.
>  
>  
> 1) Section 3.1.  Secure RTP
>  
>    The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly
>    used mechanisms to provide confidentiality, integrity protection and
>    source authentication for RTP.
>  
> Another security property that is explicitly mentioned in RFC 3711 is
> replay protection.

Added

>  
> 
> 2) Section 3.1.1.  Key Management for SRTP: DTLS-SRTP
>  
>    A Datagram Transport Layer Security extension exists for establishing
>    SRTP keys [RFC5763][RFC5764].  This extension provides secure key-
>    exchange between two peers, including perfect forward secrecy and
>    enabling binding strong identity verification to an end-point.
>  
> I wonder if the security properties of DTLS-SRTP actually depend on the
> ciphersuite the endpoints negotiate during the DTLS handshake.For
> example, when client and server agree on the ciphersuite
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA they perform a Diffie-Hellman key
> agreement; in this case DTLS-SRTP provides PFS.Whereas when they agree
> on TLS_RSA_WITH_AES_128_CBC_SHA the client encrypts a shared secret with
> the server's public key; and in that case PFS is not provided.To meet
> the security goals, the ciphersuites that the client can offer and the
> server can accept need carefully be selected.

You are correct. I changed the quoted sentence to say that it enables
PFS and then added this new paragraph:

The actual security properties of an established SRTP session using DTLS
will depend on the cipher suits offered and used. For example some
provides perfect forward secrecy (PFS), while other do not. When using
DTLS the application designer needs to select which cipher suits that
DTLS-SRTP can offer and accept so that the desired security properties
are achieved.


>  
> 
> 3) Section 3.1.2.  Key Management for SRTP: MIKEY
>  
> Pre-Shared Key mode:
>  
>    This system is the most efficient from the perspective of having
>    small messages and processing demands.
>  
> The downside is scalability. Usually, the effort for the provisioning of
> pre-shared keys is only manageable, if the number of endpoints is small.

Added a sentence on this.

Uses a pre-shared secret for symmetric key crypto used to secure a
keying message carrying the already generated TGK. This system is the
most efficient from the perspective of having small messages and
processing demands. The downside is scalability, where usually the
effort for the provisioning of pre-shared keys is only manageable, if
the number of endpoints is small.


>  
> 
> IBAKE mode:
>  
>    If provides both perfect forward and backwards secrecy.
>  
> I think the term perfect backward secrecy needs more clarification. In
> what exactly is it different from forward secrecy?For example, RFC 4949
> gives a definition of perfect forward secrecy and briefly discusses
> issues where experts disagree about it.Backward secrecy is mentioned in
> that context as one of the disputed issues (it seems to be a synonym for
> forward secrecy), but not precisely defined.I am not aware of a clear
> definition of this term.

Thanks for the pointer to the Internet Security Glossary. I added this
to an introduction section as a useful reference to learn about terms
the reader may not understand. Regardin IBAKE, I am not a security
expert and I don't understand the difference here. Until someone can
provide a clear short explanation I will indicate that this is unclear
and move on.

IBAKE: uses a key management services (KMS) but with lower demand on the
KMS. Claims to provides both perfect forward and backwards secrecy, the
exact meaning is unclear (See Perfect Forward Secrecy in [RFC4949]).


>  
> 
> SAKKE mode:
>  
> Requires additional infrastructure. A key management service (KMS) must
> create the secret keys associated with the identities (resp. public keys).


SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY. Based
on Identity based Public Key Cryptography and a KMS infrastructure to
establish a shared secret value and certificate less signatures to
provide source authentication. It features include simplex transmission,
scalability, low-latency call set-up, and support for secure deferred
delivery.

I think what is relevant here is to understand that this requires
infrastructure, so I added that "keyword" also to the IBAKE.

>  
> 
> 4) Section 3.1.3.  Key Management for SRTP: Security Descriptions
>  
>    Since keys are transported in plain text in SDP, they can easily be
>    intercepted unless the SDP carrying protocol provides strong end-to-
>    end confidentiality and authentication guarantees.  This is not the
>    common use of security descriptions with SIP, where instead hop by
>    hop security is provided between signalling nodes using TLS.  This
>    still leaves the keying material sensitive to capture by the
>    traversed signalling nodes.  Thus in most cases the security
>    properties of security description are weak.
>  
> I agree. The usage of security descriptions usually requires additional
> security measures, e.g. the signalling nodes be trusted and protected by
> strict access control. An example where these conditions are often given
> is an enterprise environment.Usage of security descriptions requires
> careful design in order to ensure that the security goals can be met.
> 

Took two of your sentences to add to this paragraph:

Since keys are transported in plain text in SDP, they can easily be
intercepted unless the SDP carrying protocol provides strong end-to-end
confidentiality and authentication guarantees. This is not the common
use of security descriptions with SIP, where instead hop by hop security
is provided between signalling nodes using TLS. This still leaves the
keying material sensitive to capture by the traversed signalling nodes.
Thus in most cases the security properties of security descriptions are
weak. The usage of security descriptions usually requires additional
security measures, e.g. the signalling nodes be trusted and protected by
strict access control. Usage of security descriptions requires careful
design in order to ensure that the security goals can be met.



> 
> 5) Section 3.1.4.  Key Management for SRTP: EKT
>  
>    Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP
>    extension that enables group keying despite using a keying mechanism
>    that can't support group keys, like DTLS-SRTP.
>  
> A second use case also described in the EKT draft is interoperability
> between different key management systems.

Correct, and the intention with the last sentences in the first
paragraph was to elude to this when discussing gateways. However, I
guess being explicit is better so I added a sentence for this:

Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP
extension that enables group keying despite using a keying mechanism
that can't support group keys, like DTLS-SRTP. It is designed for
centralized conferencing, but can also be used in sessions where an
end-points connect to a conference bridge or a gateway, and need to be
provisioned with the keys each participant on the bridge or gateway uses
to avoid decryption encryption cycles on the bridge or gateway. This can
enable interworking between DTLS-SRTP and for example security
descritptions or other keying systems where either part can set the key.


>  
> 
> 6) Section 4.1.3.  Source Authentication
>  
> Binding the Source:
>  
>       For example, consider a point to point communication system that
>       use DTLS-SRTP using self-signed certificates for key-management,
>       and SIP for signalling.  In such a system the end-points for the
>       DTLS-SRTP handshake have securely established keys that are not
>       visible to the signalling nodes.  However, as the certificates
>       used by DTLS is not bound to any PKI they can't be verified.
>       Instead, hashes over the certificate are sent over the signalling
>       path.  If the signalling can be trusted not to collaborate on
>       performaning a man in the middle attack by modifying the hashes,
>       then the end-points can verify that they have reached the peer
>       they are doing signalling with.
>  
> A second example is a key management method that transports the key
> exchange data in the signalling plane, e.g. MIKEY or security
> descriptions.Such a method ties the key exchange directly to the
> signalling. There are no additinal steps required to ensure that the
> "signalling peer" is the same as the "key exchange peer".

Added a new paragraph under this binding:

Systems where the key-exchange are done using the signalling systems,
such as Security Descriptions [RFC4568] or MIKEY embedded in SDP
[RFC4567], enables an direct binding between signalling and
key-exchange. Independent of DTLS-SRTP or MIKEY in SDP the actual
security depends on the trust one can place in the signalling system to
correctly associate the peer's identity with the key-exchange.

>  
> 
> 7) Section 4.1.4.  Identity
>  
>    ..., having an identity provider system can benefit the applications
>    by enabling them to do strong assertion between identity and the
>    actual media source.
>  
> I wonder if the draft should briefly address how identity verification
> can be achieved.The draft states several times that source
> authentication is possible using verifiable identities.I think, giving
> examples for the most widely used systems for asserting and verifying an
> identity makes reading easier.

I think you are right, but you are pushing my knowledge boundaries here.
So what are needed here?

The main methods I can think of are:
1. PKI based, where one have and use certificates to prove ones identity.

2. We have IdP based systems when have a third party Identity provider
and the user proves their identity to the IdP, which then asserts it
towards the authenticating party. Or provides short term credentials
that the user can use to prove their identity.

Assistance here would be appreciated.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------