Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-srtp-03.txt - Questions and C omments

From: Mark Baugher <[email-masked]>
Date: Mon, 11 Mar 2002 09:08:58 -0800

Martin
   Thanks so much for your careful reading of the SRTP draft.  I think Mats 
is going to respond for all of us so you don't get n responses to your two 
dozen or so points.  I think key management is the most difficult aspect of 
SRTP though it is largely out of scope for SRTP. We need for SRTP to be as 
agnostic as possible regarding key management because SRTP can be used for 
so many different applications, unicast and multicast.  What we have tried 
to do is ensure the SRTP as it is currently specified can be used by 
different key management systems for interactive voice and video as well as 
broadcast types of applications.  So the points you raise are important as 
we adapt key management protocols (e.g. MIKEY, GDOI) to serve SRTP.

regards, Mark
At 11:17 AM 3/11/2002 +0100, Euchner Martin  ICN M SR 3 wrote:
>Dear SRTP editors,
>
>Let me first say that SRTP-03 looks like really great work!
>
>Below I have compiled several questions and comments upon SRTP that I came
>across during my review. Most of them are probably just editorial, none is
>certainly controversial I believe. Certainly, some portions of the text
>could be editorially clarified.
>
>Most of the questions are for clarification and relate to my interest in
>understanding the issue of the SRTP/SRTCP interface to external key
>management. I feel that this latter issue is not absolutely clearly
>described in this paper. Thus, the question is if some additional paper
>addressing that might be deemed useful (see also Q.18).
>
>
>I've named each question with a number, showed the reference to SRTP-03.txt
>with section number and mostly also a short quote >> ...<< from the text.
>
>Q.1) Reference: section 3.1.1 and entire document.
>
>                 The question I had when reading the document from the
>beginning to the end sequentially is:
>                 Is there one common master key for both SRTP and SRTCP or
>are there separate master keys?
>
>                 My understanding is that for the default behavior there is
>only one common master key. But in the general case, there might also be two
>distinct master keys in different crypto contexts; one for the SRTP context
>and another one for the SRTCP context. If that is true, then my
>recommendation is to cleanly separate the notion of crypto context and
>master key from the default behavior as a special case.
>
>Q.1.1) Reference: section 3.1.1 >>* the master key(s),<<
>
>                 How many master keys does a single cryptographic context
>actually hold? My understanding is that there is just one master key per
>crypto context. But if there could be more than one master key in a single
>crypto context then what are those good for?
>
>Q.1.2) Reference: section 3.1.1 >> The transform-independent parameters of
>the cryptographic context for SRTP consist of:<<
>
>                 I miss a similar section for the cryptographic context for
>SRTCP. Or is it such that the sentence should read "The
>transform-independent parameters of the cryptographic context for SRTP or of
>the cryptographic context for SRTCP consist of" ?
>
>Q.1.3) Reference: section 3.1.1 >> Note in particular that the master key(s)
>MAY be shared between SRTP and SRTCP, if the pre-defined transforms
>(including the key derivation) are used but the session key(s) MUST NOT be
>so shared.<<
>
>                 It appears clearer to use the notion of shared crypto
>contexts for the default case where the shared SRTP and SRTCP crypto context
>hold the same master key. But see also my problems with the plural (s) as in
>Q.1.1.
>
>Q.2) Reference Section 3 Figure 1 and section 3.3 Figure 2
>
>                 SRTP and SRTCP do not protect the optional MKI fields in
>terms of confidentiality and integrity. What is the reason for excluding
>them from any protection? This violates the goal stated in section 2 >>the
>integrity protection of the entire RTP and RTCP packets, together with
>protection against replayed packets.<<
>
>                 Couldn't there be certain (let's say DoS/replay)
>intentional/unintentional attacks by manipulating the MKI field? Yet, I do
>not see any other useful attacks beyond that.
>
>                 Thus, my recommendation is to include the MKI fields in SRTP
>and SRTCP in the encrypted and authenticated portion.
>
>Q.3) Reference: Section 3 >>The Authenticated Portion of an SRTP packet
>consists of the RTP header followed by the Encrypted Portion of the SRTP
>packet.<<
>
>                 This sounds confusing in the case where SRTP does not
>encrypt the payload (NULL encryption) but only provides integrity. Then,
>there is not any encrypted portion in the payload, but only an unencrypted
>portion.
>
>Q.4) omitted
>
>Q.5) Reference: section 3.1.3 "RTP session, cryptogr. context", and section
>12.1.2
>
>                 Is my understanding correct that a cryptographic context
>corresponds to an RTP session? From section 12.1.2 I got the impression that
>a cryptographic context relates to a unidirectional RTP stream.
>
>                 I further assume that each cryptographic context is
>associated with a particular master key, thus different cryptographic
>contexts generally relate to different master keys.
>
>                 However, the same master key can be shared between the SRTP
>and the SRTCP cryptographic context (default case); right?
>
>Q.6) Reference: section 3.2.2 >>Each SRTP receiver maintains a Replay List,
>which conceptually contains the indices of all of the packets which have
>been received and authenticated<<
>
>                 Shouldn't the "replay list" be actually renamed as
>"Authenticated List" as none of the indices in that list refers to a
>replayed packet?
>
>Q.7) Reference: section 3.3 "SRTCP index"
>
>                 Why does SRTCP use an explicit SRTP index but SRTP uses just
>an implicit index? Why not use an explicit SRTCP index too? I'm not
>indicating anything wrong of the SRTP concept, this is merely for my
>curiosity.
>
>Q.8) Reference: section 4.2 "Common parameters"
>
>                 The enumeration does not show the authentication algorithm
>as parameter while section 4.1 shows the BLOCK_CIPHER. I believe an AUTH_ALG
>should be added too.
>
>Q.9) Reference: section 4.2 "Common parameters"
>
>                 What is "M"? Is that really a parameter or rather the input
>packet portion? I suggest deleting that entry in the common parameters here
>since an "E" parameter in section 4.1 is not mentioned either.
>
>Q.9.1) Reference: section 4.2.2 >> k_a as obtained by applying the key   *
>           derivation.<<
>
>                 The star is probably just a typo?
>
>Q.9.2) Reference: section 4.2.1 "HMAC/SHA1"
>
>                 Since this HMAC is actually a 32-bit truncated variant I
>would suggest phrasing the title as "HMAC-SHA1-32".
>
>Q.10) Reference: section 6 "SRTP_WINDOW-SIZE"
>
>                 Is it true, that SRTP-WINDOW-SIZE is a local parameter of
>the receiver that does not need to be negotiated by external key management?
>
>Q.11) Reference: section 7 >>Whenever a new transform is to be added to
>SRTP, a companion standards-track RFC MUST be written to exactly define how
>the new transform can be used with SRTP (and SRTCP).<<
>
>                 Why is it required that a companion RFC to SRTP be standards
>track? Can't there be just a companion informational RFC for example?
>
>Q.12) Reference: section 8.2 >>As the TMMH keys may be quite large, the key
>derivation provides a simple and secure way to obtain sufficient amount of
>keying material.<<
>
>                 Perhaps is can be noted here or in the security
>consideration section that the effective key entropy of the large TMMH
>authentication key is not more than the entropy of the shorter session key.
>
>Q.13) Reference: section 8.3 >> We envision a migration to TMMH so that HMAC
>may eventually be phased-out from SRTP.<<
>
>                 I certainly understand the visionary intention here but I
>also seriously question the practical feasibility. It can be observed that a
>phase-out or revocation of "ancient" products, versions does not really
>occur in the market (just look at MSDOS). So my question here is: what is
>the underlying concept of versioning and product maintenance?
>
>                 More specifically, let me further ask how SRTP would deal
>with encountered security fixes at some later point in time? Is there a
>backwards-compatible way how to incorporate fixes? This is probably much
>more of a concern regarding the MIKEY key management protocols that might
>have some unknown flaws today.
>
>Q.14) Reference: section 8.4 >>However, in group scenarios where the keys
>are shared between members, the MAC tag only proves that a member of the
>group sent the packet, but does not prove the actual sender.<<
>
>                 This is of course true. Nevertheless, group-based media
>integrity/authentication with symmetric methods (SRTP) still has its value
>within a group to protect against outsiders, despite it does not work on an
>individual basis. This can be pointed out.
>
>Q.15) Reference: section 8.4 >> The presence of mixers and translators does
>not allow data origin authentication in case the RTP payload and/or the RTP
>header are manipulated.<<
>
>                 It appears wise to deprecate usage of mixers and translators
>for SRTP.
>
>Q.16) Reference: section 9 >> For initialization, the key management needs
>to be given the SSRC and initial RTP sequence-number for the RTP stream, and
>thus has a dependency on RTP operational parameters.<<
>
>                 Does this dependency relate to the generation of the master
>key and external key management or rather on the key derivation? I would
>hope that latter is true, since the SSRC might not be known yet when the
>master key is created.
>
>Q.17) Reference: section 9 >> A particular key management system might
>choose to provide re-key by associating a master key for a crypto
>context...<<
>
>                 My understanding of the SRTP re-key mechanism is that it
>applies to newly derived session keys for an unchanged master key. I guess
>that there is no such thing defined as re-keying of master keys. If that
>would become necessary than shutdown of the session and re-opening with a
>new master key would be the only method.
>
>Q.18) Reference: section >> These interactions are defined by the key
>management interface to SRTP and are not defined by this protocol
>specification.   <<
>
>                 Where is that interface to an external key management
>defined? From hard reading of SRTP one might deduce such an interface, but I
>consider a compound description of such an interface more than useful. Is
>there more interest in this group to work on such a (perhaps informational)
>companion document?
>
>                 Now that I have studied also MIKEY-01.txt, I can see there
>the SRTPbasic policy and SRTPext policy described in section A.10.1 and
>A.10.2. This already comes very close to what I consider as key management
>interface above. So for the time being, a pointer to those sections might
>suffice.
>
>Q.18.1) Reference: section 10.4
>
>                 I'm just curious to understand how SRTP/SRTCP header
>confidentiality relates to privacy/anonymity; especially the encrypted SSRC
>and SSRS identifiers. May you consider adding these issues?
>
>Q.19) Reference: section 10.5 >> The IV formation of the f8-mode gives
>implicit authentication (IHA) of the RTP header, even if no cryptographic
>integrity protection is present.<<
>
>                 This is certainly true. But what about SICM that would
>provide some very, very limited "IHA" too (only SSRC is covered)? However, I
>wouldn't consider any IHA for SICM as a design goal for SRTP.
>
>Q.19.1) Reference: section 10.5, section 2
>
>                 What can be said in this document about denial-of-service
>attacks that are countered by the RTP/RTCP packet authentication? I consider
>deployment of the authentication/integrity mechanisms useful in being able
>to quickly filter out spam RTP/RTCP packets from unauthorized sources and
>thereby saving any further valuable processing resources such as FEC,
>decryption and codec decoding operations. Perhaps you may consider adding a
>new sub-section on how SRTP/SRTCP counter and address DoS attacks.
>
>Q.20) Reference: section 11 >> The optimal order would be the following:  -
>on the sender side, first encrypt the packet, then perform the FEC
>processing, finally authenticate <<
>
>                 A different order (1st authenticate packet, 2nd FEC and then
>encrypt) on the sender side would have the benefit that
>authentication/integrity could be preserved in case of FEC-correctable bit
>errors. However, this mode might expand the packet size for encryption. The
>trade-off might not be that significant for "short" payloads but the DoS
>risk is increased and slight redundancy is added to the plaintext.
>
>                 I'm not quite certain whether the order (1st authenticate,
>2nd encrypt, and then FEC) might have a case as well (for burst errors
>perhaps?). At least this mode has the benefit of co-locating the security
>functions (authentication and encryption) together and having the FEC
>directly operate on the data portion; thus being able to re-cover destroyed
>RTP header fragments as well.
>
>                 By FEC I assume that actually a scheme is meant that applies
>error correction codes to the payload or packet but not ARQ.
>
>                 Further, I do not understand the notion of "optimal" since
>it does not state any constraints or criteria. I could better live with the
>word "suggested order" instead.
>
>                 Thus, all three FEC placements might occur (theoretically).
>I consider the FEC placement an issue that perhaps the external key
>management would negotiate and signal or even some other out-of-band
>signaling. A parameter might be added to the crypto context, stating default
>or one of the non-default orders.
>
>Q.21) Reference: section 10.5 >> The use of error detection mechanism (e.g.,
>Unequal Error Detection, UED and UEP) is compatible with SRTP and the
>pre-defined encryption transforms, since stream ciphers maintain the
>position of the bits.<<
>
>                 You may add here informational references for UXP and ULP.
>
>Q.22) Reference: section 12.1.2 >>One master key per party<<
>
>                 You may change the title to "Two unidirectional RTP streams"
>(similar to section 12.1.1).
>
>
>
>I'm looking forward to your response. In any way, we could discuss these
>things at length also in Minneapolis...
>
>
>
>
>With kind regards
>
>Martin Euchner.
>-----------------------------------------------------------------------
>| Dipl.-Inf.                     Rapporteur Q.G/SG16
>| Martin Euchner                 Phone: +49 89 722 55790
>| Siemens AG.....................Fax  : +49 89 722 47713
>| ICN M SR 3                     mailto:[email-masked]
>|                                mailto:[email-masked]
>| Hofmannstr. 51                 Intranet:
>http://intranet.icn.siemens.de/marketing/cs27/topics/security/
>| D-81359 Muenchen               Internet: http://www.siemens.de/
>| __________________
>| Germany
>-----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Elisabetta Carrara (ERA)" <[email-masked]>
Date: Tue, 12 Mar 2002 16:27:30 +0100

Hello Martin,
thanks a lot for your comments
I will answer in-line to the questions (except the one related to FEC,
that David has discussed separately)

> master key from the default behavior as a special case.

By default, yes, all parameters except the ones that MUST be distinct(e.g.
replay lists; they are listed in thet draft) are shared between SRTP 
and SRTCP. The context lookup procedure will typically be implemented 
to give you the same context for SRTP and SRTCP, hence the master key
will be shared. 

However, we do mention an option to maintain separate contexts for SRTP
and SRTCP in which case you MAY have all the parameters separated 
(including master key).

Thus, it is not enough to separate the master key from the discussion as
any or (almost) all parameters MAY be shared. In fact, if only the master key
is "separated" it would not be correct.

> crypto context then what are those good for?

Typically, yes, you have one master key per crypto context. 
But you could envision some scenarios (e.g., pay per view) where
key management gives you several, consecutive keys in advance and at once,
so that you can switch keys on the fly. 
(Not sure this is the best example, but surely there are others.)
These keys will have associated lifetime.

> the cryptographic context for SRTCP consist of" ?

No, read it as it is. We list the differences for SRTCP after that: 
"SRTCP by default uses the same cryptographic context parameters, except..." 
(the "default" here is due to the above discussion of keeping separate contexts for
SRTCP)

> hold the same master key. But see also my problems with the 

hope the discussion before has clearified

> and SRTCP in the encrypted and authenticated portion.

The MKI's inclusion was considered and we found that there is no point in
authenticating the MKI: exactly the same attacks are possible in either
cases.

The effect of modifying the MKI field (whether authenticated or not) in
transit is that the receiver will use the wrong key. However, there is a priori no
way for him to tell if the key is wrong or not, else we wouldn't need the MKI. This
will cause authentication and decryption to fail in both cases. 

Of course, we would be happy to review the specific attacks you have in
mind to see that we did not miss anything.

> there is not any encrypted portion in the payload, but only 

NULL-encryption is also a form of encryption...
to address this concern, we added the bracket at the beginning of section 3:

"The Encrypted Portion of an SRTP packet consists of the encryption of
the RTP payload of the equivalent RTP packet. (Our use of the word
'encryption' includes also the possibility of a 'NULL'-encryption.)"

However, the terminology we have used has other times raised misunderstanding.
We will consider if to change the terminology, or add explanation.

> 
> Q.4) omitted
> 
> Q.5) Reference: section 3.1.3 "RTP session, cryptogr. 
> context", and section 12.1.2
> 

both are possible

> and the SRTCP cryptographic context (default case); right?
yep, as default.

Please note, Martin: this matter enters key mgmt, which is not really in the 
scope of the spec. We wanted to make SRTP very flexible, allowing
different key mgmt policies in different scenarios. If you read section
"Scenarios" maybe it's clearer, we added this section to provide guidance 
in cases such the one you mention.  
In general, we strived to make the number of keys in place as small as
possible. For instance, we also allow different RTP sessions to share master 
keys *if* you can guarantee that they use different SSRCs.  

> "Authenticated List" as none of the indices in that list refers to a

well, the name might not exist somewhere else, however the terms are more
or less present, say, in IPsec.
We can rename to Anti-Replay List, better? 

> indicating anything wrong of the SRTP concept, this is merely for my

there is no sequence number in RTCP to be used for synch, and also,
while SRTP does not use an added "index field" because we wanted not to 
increase bandwidth, RTCP traffic is less frequent, hence bandwidth
effects give less impact. 

> as parameter while section 4.1 shows the BLOCK_CIPHER. I 

ok

> 		What is "M"? 

	" M is the Authenticated Portion as specified in Section 3 for RTP 
  	and in Section 3.3 for RTCP."

>Is that really a parameter or 
> rather the input

yes, thanks

> would suggest phrasing the title as "HMAC-SHA1-32".

We considered it, but then we decided not to use the way you say, 
since you then need one algorithm identifier for
each possible tag-length. Rather, HMAC-SHA1 is the algorithm, and n_tag is
the size of the tag.

> the receiver that does not need to be negotiated by external 

yes, it is by default 64. However, the value needs to be a good 
choice, depending on the scenario/application.

> track? Can't there be just a companion informational RFC for example?

well..we are indeed not sure..we might delete 'standard-track', or better,
we'll ask Colin and Stephen. 

> authentication key is not more than the entropy of the 

Possibly. Note that the purpose of the TMMH key is only to make sure collision probabilities
are what they should be. The TMMH key in itself gives no real protection
for integrity, that comes more from the combination with the XOR of the 
cipher output.

> have some unknown flaws today.

well...
*If* it should turn out that something is wrong, we still cannot answer this
question, since the action taken would depend on the flaw found. 
however, this is a problem common to any IETF protocol,
there are procedures to follow. 
About MIKEY, note that SRTP is standalone, it is not depending
on MIKEY or any other protocol of that kind. The opposite holds,
MIKEY is not dependent on SRTP.

> individual basis. This can be pointed out.

if you want...
however, it is not in the scope of SRTP to explain general security concepts.

> 		It appears wise to deprecate usage of mixers 

a trusted mixer/translator could decrypt / re-encrypt.
It can be the an SRTP endpoint.

> hope that latter is true, since the SSRC might not be known 

the SSRC is used in the crypto context identifier. So the parties 
need it in advance. 

> new master key would be the only method.

no.
'Re-keying' in SRTP means new master key.
'Key derivation' means deriving session keys.

> interface above. So for the time being, a pointer to those 

Section 9 was intended for this.
Do you think it is not enough ?

> and SSRS identifiers. May you consider adding these issues?

user privacy was not in the scope for SRTP.
If requested, we might take the issue under examination.
Note however, user privacy cannot be solved by a security protocol alone.

> wouldn't consider any IHA for SICM as a design goal for SRTP.

No, that's right. It wasn't a goal for f8 either, more of a "bonus".

> new sub-section on how SRTP/SRTCP counter and address DoS attacks.

the default order was thought to minimize DoS effects.

> 		A different order (1st authenticate packet, 2nd 
> FEC 

(...skipped. See David's mail)

> things at length also in Minneapolis...

good.

Many thanks,
cheers.