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

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Mon, 11 Mar 2002 11:17:53 +0100

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: "David A. Mcgrew" <[email-masked]>
Date: Mon, 11 Mar 2002 10:46:10 -0800

Martin,

many thanks for your detailed comments.  Below is an explanation of our
reasoning about the relative ordering of security processing and
packet-level forward error correction, and some discussion on the same.
(Mats and others will be replying to your other points separately).

> or one of the non-default orders.

The short answer is: we specified only one ordering of SRTP and FEC for
simplicity's sake, and our choice of orderings was perhaps somewhat
arbitrary but probably reasonable.  The long answer is below.

For completeness, Let's consider all the possible orderings of
encryption/decryption (enc/dec), authentication (auth), and forward error
correction (fec) encoding/decoding.  There are eight possibilities, but we
can reject options which would cause decryption to precede auth verification
on the receiver side.  This is because authentication is cheaper than
decryption by as much as an order of magnitude, and we want to order the
operations in order to protect against DoS attacks.  That leaves three
options, which I've listed below:

    Sender               Receiver
1.  enc auth fec         fec auth dec
2.  fec enc auth         auth dec fec
3.  enc fec auth         auth fec dec

Option #1 is vulnerable to DoS attacks against the receiver's FEC buffers.
The other options don't have this problem.

Option #2 essentially provides the attacker with lots and lots of known
plaintext, due to the linear equations used in the FEC.  The other options
don't have this problem.  Also, this option expands the amount of data that
needs to be cryptographically processed, increasing the computational load.

Option #3 expands the amount of data that needs to be authenticated, but not
the amount of data that needs to be encrypted.  Another problem with Option
#3 is that it doesn't make the security processing atomic.  The security
subsystem would need to pass data to the FEC subsystem which would then need
to return that data to the security subsystem, or the two systems would need
to be integrated.

With AES or a similarly strong cipher, the known plaintext issue of Option
#2 isn't really a problem.  This leaves the tradeoffs of the FEC DoS
vulnerability versus the increased computational load.  We chose Option #1
to minimize the computational load (and apparently didn't discuss the issue
well enough in the rationale).  Option #2 is also perfectly reasonable.  We
chose to mandate the SRTP/FEC ordering in order to reduce the complexity of
implementations, and not because Option #2 would be a poor choice.

Option #3 can be viewed as an optimization of #2.  I favor not allowing this
option, as complexity and security are incompatible and this option would
add considerable complexity to an implementation, whereas the other options
can be implemented without any changes to the SRTP packet processing
definition.

If we do allow more than one option, then we'd need to provide a way to
signal which option would be in use.  I suppose that SRTP could add
parameter to those passed by key management which indicated which option was
in use, though I can't vouch that this method would work with any and all
FEC mechanisms.  Also, if we were to allow only Options #1 and #2, then the
changes to the existing SRTP spec would be minimal.  If we were to allow
Option #3, then the changes would be much more involved; we would have to
change the packet processing algorithm to accommodate a way to send/recv
packets to and from a FEC mechanism.

I'd be glad to hear your thoughts.

thanks,

dam

David A. McGrew, Ph.D.
Manager, Strategic Crypto Development
IOS Technologies Division
Cisco Systems, Inc.
(301) 349 5815

---

From: "Marshall Eubanks" <[email-masked]>
Date: Sun, 17 Mar 2002 22:19:52 -0500

On Mon, 11 Mar 2002 10:46:10 -0800
 "David A. Mcgrew" <[email-masked]> wrote:
> > Q.20) Reference: section 11 >> The optimal order would
> be the
> > following:  -
> > errors. However, this mode might expand the packet size
> for
> > encryption. The
> > directly operate on the data portion; thus being able
> to re-cover
> > destroyed
> > it does not state any constraints or criteria. I could
> better
> > live with the
> > signaling. A parameter might be added to the crypto
> context,
> > stating default

I should point out that if you are doing any sort of  
lossy erasure protection (which is very useful in streaming,
media and which we do operationally), and you wish to use
srtp, then you are basically stuck doing Option 2. I would
recommend that Option 2 be kept as a legal option.

                                 Regards
                                 Marshall Eubanks

T.M. Eubanks
Multicast Technologies, Inc.
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : [email-masked]
http://www.multicasttech.com

Test your network for multicast : 
http://www.multicasttech.com/mt/
 Status of Multicast on the Web  :
 http://www.multicasttech.com/status/index.html

---

From: "David A. Mcgrew" <[email-masked]>
Date: Mon, 25 Mar 2002 13:35:50 -0800

> -----Original Message-----
> From: Marshall Eubanks [mailto:[email-masked]]
> Sent: Sunday, March 17, 2002 7:20 PM
> To: David A. Mcgrew; Euchner Martin ICN M SR 3; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-srtp-03.txt - Questions and
> Comments
>
>

Marshall,

thanks for your input.  What would you think of mandating Option 2 and
disallowing the other two options?

thanks,

David

---

From: "Marshall Eubanks" <[email-masked]>
Date: Mon, 25 Mar 2002 20:03:51 -0500

On Mon, 25 Mar 2002 13:35:50 -0800
 "David A. Mcgrew" <[email-masked]> wrote:
> > > (Mats and others will be replying to your other
> points
> > > separately).
> > >
> > > > 		A different order (1st authenticate packet, 2nd
> FEC
> > > and then
> > > > authentication/integrity could be preserved in case
> of
> > > FEC-correctable bit
> > > > risk is increased and slight redundancy is added to
> the
> > > plaintext.
> > > >
> > > > 2nd encrypt, and then FEC) might have a case as
> well
> > > (for burst errors
> > > > functions (authentication and encryption) together
> and
> > > having the FEC
> > > > 		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
> > > > I consider the FEC placement an issue that perhaps
> the
> > > external key
> > > The short answer is: we specified only one ordering
> of
> > > SRTP and FEC for
> > > arbitrary but probably reasonable.  The long answer
> is
> > > below.
> > >
> > > encryption/decryption (enc/dec), authentication
> (auth),
> > > and forward error
> > > on the receiver side.  This is because authentication
> is
> > > cheaper than
> > > decryption by as much as an order of magnitude, and
> we
> > > want to order the
> > > operations in order to protect against DoS attacks.
> That
> > > leaves three
> > > Option #2 essentially provides the attacker with lots
> and
> > > lots of known
> > > plaintext, due to the linear equations used in the
> FEC.
> > > The other options
> > > don't have this problem.  Also, this option expands
> the
> > > amount of data that
> > > needs to be cryptographically processed, increasing
> the
> > > computational load.
> > >
> > > the amount of data that needs to be encrypted.
> Another
> > > problem with Option
> > > subsystem would need to pass data to the FEC
> subsystem
> > > which would then need
> > > to return that data to the security subsystem, or the
> two
> > > systems would need
> > > to be integrated.
> > >
> > > #2 isn't really a problem.  This leaves the tradeoffs
> of
> > > the FEC DoS
> > > vulnerability versus the increased computational
> load.
> > > We chose Option #1
> > > to minimize the computational load (and apparently
> didn't
> > > discuss the issue
> > > chose to mandate the SRTP/FEC ordering in order to
> reduce
> > > the complexity of

That is what I would suggest. I think that any sort of
"layered" congestion / bandwidth control would require
that encryption be done on the outermost layers of the
onion.

And, don't forget, most streaming media encodings are
compressions as well, so they have to be preformed _before_
any encryption.

Marshall
> > > option, as complexity and security are incompatible
> and
> > > this option would
> > > add considerable complexity to an implementation,
> whereas
> > > the other options
> > > can be implemented without any changes to the SRTP
> packet
> > > processing
> > > definition.
> > >
> > > If we do allow more than one option, then we'd need
> to
> > > provide a way to
> > > signal which option would be in use.  I suppose that
> SRTP
> > > could add
> > > in use, though I can't vouch that this method would
> work
> > > with any and all
> > > FEC mechanisms.  Also, if we were to allow only
> Options
> > > #1 and #2, then the
> > > changes to the existing SRTP spec would be minimal.
> If
> > > we were to allow
> > > Option #3, then the changes would be much more
> involved;
> > > we would have to
> > > change the packet processing algorithm to accommodate
> a
> > > way to send/recv