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

From: "Martin Euchner" <[email-masked]>
Date: Sun, 17 Mar 2002 22:51:06

Elisabetta,

thank you so much for your comprehensive answer. This has helped me a lot in understanding SRTP.

Let me just comment on two issues:

> 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.

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.

MEU:> Yes, some explanation might be useful indeed, since null-encryption might be misleading: People should not believe that Null-encryption provides any actual encryption or any measure of security. The truth is that null-encryption provides just null-security which is unfortunately just no security at all.

> 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.

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

MEU:> I consider section 9 as some high-level information on what the key management should provide for SRTP. I'm looking for some more detailed menu such as a decision tree of alternative options etc, i.e. what the key management should actually negotiate as parameters, keys, options etc. I do not say that that this must necessarily be part of the SRTP spec; this could be a separate documents as well. However, since the MIKEY uses different terminology (GSEC group terms), I would pretty much see some generic key management interface that is close to SRTP.

With kind regards,

Martin Euchner.

+---------------------------------

+

+ email: [email-masked]

+

+---------------------------------

Get your FREE download of MSN Explorer at http://explorer.msn.com.

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

---

From: Mats Näslund <[email-masked]>
Date: Mon, 18 Mar 2002 10:55:31 +0100

Thanks for the comments Martin,

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

Yes, there is. There is *always* an encrypted portion since we *define*
it that way: the encrypted portion is produced by an encryption
algorithm,
sometimes this algorithm happens to be the NULL-algorithm.

Some of the SRTP authors argued in favor of calling it the "confidential
portion". However, there I think your argument is applicable: it is not
cinfidential if it was produced by the NULL-algorithm.

> MEU:> Yes, some explanation might be useful indeed, since
> null-encryption might be misleading: People should not believe that
> Null-encryption provides any actual encryption or any measure of
> security. The truth is that null-encryption provides just
> null-security which is unfortunately just no security at all.

IMO it does provide encryption, but not "confidentiality", "secrecy", or 
"data privacy". Even protocols such as IPsec specify a NULL-transform.

We will see what we can do to make this clearer.
 
> MEU:> I consider section 9 as some high-level information on what the key management should provide for SRTP. I'm looking for some more detailed menu such as a decision tree of alternative options…

I think we agree that MIKEY should be clearer in how it relates to SRTP.
Fredrik suggested some "table" for this. It will also be easier to do
that now that SRTP is (more or less) completely stable.

Best,

/Mats