Subject: [AVT] SRTP comments

From: [email-masked]
Date: Mon, 27 May 2002 11:51:50 +0300

Hi there,

I have some questions concerning srtp draft:

 - I guess that the calculation of IV (x*2^16) belongs to the 4.3.1 section and not to 4.3.3?

 - Same is with the calculation of IV for the encryption/decryption; if 4.1.1 is named "AES in Counter Mode" it means that here just pure AES-CM should be explained, and all SRTP encryption specific stuff (like calculation of IV for encryption/decryption) should be somewhere else?

 - is it so that in key derivation (so AES-CM PRF) the keystream we get is already the key we need? So we don't do any XORing in the end? Then it means that key derivation doesn't use the whole AES-CM, but skips the last part? Or is the XORing not part of AES-CM?

--------------------------

 - in Appendix B.2 there are the test vectors for AES-CM. If we take e.g. Salt (I guess here it should be session salting key) and shift it 2 bytes to the left (the operation "k_s * 2^16"), the left two bytes will be cut off. I guess this example vector should be the other way around (the two zero-bytes belong to the left side of the vector)? Then they are cut off and everything is fine?

 - in Appendix B.3 it says Key Derivation _and_ PRF test vectors. Which vectors are for Key derivation and which for PRF? What is the difference between Key Derivation and AES-CM PRF anyway (I thought it is the same thing)?
 
 - in Appendix B.3, there is a confusion regarding the key names. Previously named "session encryption key", "session authentication key", and "session salting key", appear to be here named "cipher key", "auth key", and "cipher salt". It also says that the latter three are first called "16 octet key", "14 octet salt" and "94-octet authentication key". Could you please clarify this a bit?

 - As this AES-CM PRF flow is demonstrated, it says "AES input" and "AES output". I guess that would be "AES-CM input" and "AES-CM output"? 

--------------------------

 - what should "seekable" stream cipher mean?

 - is it so that both Master Salt and session salting key are used to protect against off-line key-collision attacks (off-line pre-computation attacks)? Do these latter two expressions mean the same thing? What is it?     

Thanks in advance for your answers,
Kind regards,

  Eva Kunstelj
---------------------------------
[email-masked]

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

---

From: "Elisabetta Carrara (ERA)" <[email-masked]>
Date: Mon, 27 May 2002 16:07:35 +0200

Hello Eva,

> 4.3.1 section and not to 4.3.3?

The "x*2^16" was moved from Sect 4.3.1 to Sect 4.3.3 because it 
is dependent on the PRF you use. 

> 
>  - Same is with the calculation of IV for the 
> encryption/decryption; if 4.1.1 is named "AES in Counter 
> Mode" it means that here just pure AES-CM should be 
> explained, and all SRTP encryption specific stuff (like 
> calculation of IV for encryption/decryption) should be somewhere else?

It is written in that way. The IV is transform-specific,
i.e. that IV is AES-CM specific.

> 
>  - is it so that in key derivation (so AES-CM PRF) the 
> keystream we get is already the key we need? So we don't do 
> any XORing in the end? Then it means that key derivation 
> doesn't use the whole AES-CM, but skips the last part? Or is 
> the XORing not part of AES-CM?

yes, it is the key (session key).
If the xoring you mean is the xoring between the keystream and the plaintext
for a stream cipher, the answer is no, you don't use the xor there.
The session key is fed 'again' into AES-CM. You get again a 
keystream, and that one you xor with the plaintext.

I'd not define the xoring as 'part of' AES-CM, it is part of the usage 
of AES-CM, i.e. the xor is part of the 'encryption', not of
the 'keystream generation'.  

>  - in Appendix B.2 there are the test vectors for AES-CM. If 
> we take e.g. Salt (I guess here it should be session salting 
> key) 

yes, it is the session salt, already shifted (we should specify this)

>and shift it 2 bytes to the left (the operation "k_s * 
> 2^16"), the left two bytes will be cut off. I guess this 
> example vector should be the other way around (the two 
> zero-bytes belong to the left side of the vector)? Then they 
> are cut off and everything is fine?

If the salt was larger than 112 bits, yes it would be cut off, but the
salt is 112 bits.

> 
>  - in Appendix B.3 it says Key Derivation _and_ PRF test 
> vectors. Which vectors are for Key derivation and which for 
> PRF? What is the difference between Key Derivation and AES-CM 
> PRF anyway (I thought it is the same thing)?

the key derivation is implemented by the PRF.
The test vectors are for the key derivation, using the PRF
implemented as AES-CM.

>  
>  - in Appendix B.3, there is a confusion regarding the key 
> names. Previously named "session encryption key", "session 
> authentication key", and "session salting key", appear to be 
> here named "cipher key", "auth key", and "cipher salt". It 
> also says that the latter three are first called "16 octet 
> key", "14 octet salt" and "94-octet authentication key". 
> Could you please clarify this a bit?

yes, App A.3. says: 

*..a 16 octet key and a 14 octet salt, and an 
   authentication function which requires a 94-octet authentication 
   key. These values are called the cipher key, the cipher salt, and 
   the auth key in the following.*

We choose to change the names to shorten. 
Which kind of clarification would you like here? 
don't change the names, or? I think the names are 
quite clear in that context...

> 
>  - As this AES-CM PRF flow is demonstrated, it says "AES 
> input" and "AES output". I guess that would be "AES-CM input" 
> and "AES-CM output"? 

yes
In the case when there is only one block to produce, it is the same
thing though ;o)

it means that the stream cipher is able to efficiently seek to 
arbitrary locations in its keystream. This is to overcome 
packet loss and not-ordered delivery (one of SRTP design goals). 

> 
>  - is it so that both Master Salt and session salting key are 
> used to protect against off-line key-collision attacks 
> (off-line pre-computation attacks)? Do these latter two 
> expressions mean the same thing? What is it? 

yes, attacks can search for key-collisions. These
attacks are done off-line, using some knowledge on the plaintext.
Read the beginning of Sect 9.2. 
The master salt protects against off-line attacks to the PRF/key
derivation; the session salt protects against off-line attacks on the encryption.

(I guess David would be happy to give you a detailed explanation if you 
want, he wrote some articles on this (as you can see from the reference)). 

> Thanks in advance for your answers,

Thanks to you, hope this answered.

Cheers
/E

---

From: [email-masked]
Date: Tue, 28 May 2002 12:17:46 +0300

Hi Elisabetta,

thanks for your prompt answer.

> i.e. that IV is AES-CM specific.

What I meant here that at least for me it would have been much
more comprehensive to have a separate section somewhere in the draft
(maybe in Appendix?) where only AES-CM is explained.
Then there would be one section where you explain how it is used in encryption
and then other section where it is explained how it is used in key derivation.
Like this some confusions would be avoided. (also the xoring would be clearer)

----------------------

> If the salt was larger than 112 bits, yes it would be cut off, but the
Well sure, then it makes sense, if it has been already shifted.

----------------------

> The test vectors are for the key derivation, using the PRF
Maybe it would have been then wise not to use "and", it's a bit confusing?
It sound like there is a set of vectors for Key Derivation
AND set of vectors for PRF.

----------------------

> quite clear in that context...

Well, once one understands the draft it somehow makes sense. But 
again I would suggest for the clarity reasons to write something like:
"... a 16 octet session encryption key, a 14 octet session salting key, and 
an authentication function which requires a 94-octet session 
authentication key. These values are called 
the cipher key, the cipher salt, and the auth key in the following."

The point is that there are so many notations used in the draft,
that it is essential to be consistent in their usage.

----------------------

> In the case when there is only one block to produce, it is the same
True. But still I would propose to call it AES-CM, since it says in 
section 4.3.3: "PRF_n(k_master,x) SHALL be AES in Counter Mode, as
described in Section 4.1.1., ....."
It is a bit confusing, especially if one doesn't understand the meaning of counter 
mode and sees then AES (instead od AES-CM) in test vectors section.
Again I would propose to be a bit more consistent. 

----------------------

> packet loss and not-ordered delivery (one of SRTP design goals). 
Maybe this explanation should be in the draft too? Or have I missed it
somehow?

These are mere suggestions, to make the draft more readable. :-)

Regards,

    Eva

---

From: Mark Baugher <[email-masked]>
Date: Tue, 28 May 2002 06:32:28 -0700

Hi Eva
   I mostly agree with Elisabetta's responses and have a couple of my own.

> section and not to 4.3.3?

We separate the description of the algorithm from the parameters since the 
latter may be changed in a future RFC while preserving the algorithm 
definition.  It would be bad if we required that the algorithm be 
re-specified when a future specification changes the parameters.

>  - Same is with the calculation of IV for the encryption/decryption; if 
> 4.1.1 is named "AES in Counter Mode" it means that here just pure AES-CM 
> should be explained, and all SRTP encryption specific stuff (like 

It is important that the AES-CTR specification be read first.  I think it's 
best to avoid repeating that in SRTP since this repetition can lead to 
mistakes and confusion. Personally, I found 
http://csrc.nist.gov/encryption/modes/workshop1/papers/lipmaa-ctr.pdf to be 
helpful, though it does not appear among our references.  Perhaps it should.

>  - is it so that in key derivation (so AES-CM PRF) the keystream we get 
> is already the key we need? So we don't do any XORing in the end? Then it 
> means that key derivation doesn't use the whole AES-CM, but skips the 
> last part? Or is the XORing not part of AES-CM?

The xor is definitely part of AES-CM encryption/decryption.  But I don't 
understand your point.

>  - in Appendix B.2 there are the test vectors for AES-CM. If we take e.g. 
> Salt (I guess here it should be session salting key) and shift it 2 bytes 
> to the left (the operation "k_s * 2^16"), the left two bytes will be cut 
> off. I guess this example vector should be the other way around (the two 
> zero-bytes belong to the left side of the vector)? Then they are cut off 
> and everything is fine?

Maybe we should remind the reader about the size of the salt (I had a 
similar problem with this and got confused during the final edit).  I 
should point out that David McGrew has made SRTP code available, and people 
working on an implementation should consult this work.  The SRTCP is not 
yet in the reference implementation.

>  - in Appendix B.3 it says Key Derivation _and_ PRF test vectors. Which 
> vectors are for Key derivation and which for PRF? What is the difference 
> between Key Derivation and AES-CM PRF anyway (I thought it is the same thing)?

Is it not clear that the key derivation is a prf with specified inputs and 
outputs?

>
>  - in Appendix B.3, there is a confusion regarding the key names. 
> Previously named "session encryption key", "session authentication key", 
> and "session salting key", appear to be here named "cipher key", "auth 
> key", and "cipher salt". It also says that the latter three are first 
> called "16 octet key", "14 octet salt" and "94-octet authentication key". 

I think we should.

>  - As this AES-CM PRF flow is demonstrated, it says "AES input" and "AES 
> output". I guess that would be "AES-CM input" and "AES-CM output"?

CM is built upon AES encryption.

It means that the encryption or decryption of one packet does not depend on 
preceding packets, in the SRTP case.  Perhaps we should say that.

>  - is it so that both Master Salt and session salting key are used to 
> protect against off-line key-collision attacks (off-line pre-computation 
> attacks)? Do these latter two expressions mean the same thing? What is it?

[MF00] is referenced in the security section.  We probably should reference 
it at earlier points we discuss these attacks.

thanks, Mark

---

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Wed, 29 May 2002 13:55:11 +0200

MEU:>
Yes I agree, that mentioned NIST document provides some useful reasoning;
let's add it to the informal references.

More generally, I found references [ES3D] and [ES3E] not that helpful in
understanding UMTS-f8 mode.

However, I found the following two references more comprehensive and useful
and I recommend adding them to the informal references of the SRTP spec.

3GPP TS 35.201 V3.1.1 (2001-07)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects;
3G Security;
Specification of the 3GPP Confidentiality
and Integrity Algorithms;
Document 1: f8 and f9 Specification
(Release 1999)
http://www.3gpp.org/tb/other/algorithms/35201-311.pdf

3GPP KASUMI Evaluation Report
Public Report
3rd Generation Partnership Project;
Security Algorithms Group of Experts (SAGE);
Report on the Evaluation of 3GPP Standard
Confidentiality and Integrity Algorithms
(SAGE version 2.0)
http://www.3gpp.org/tb/other/algorithms/KASUMI_Eval_rep_v20.pdf

Still, there should be some reasoning in the security consideration section
explaining
- What the security strength of AES-CM is over AES-f8 and vice versa ? And
what kind of security properties does AES-f8 feature that AES-CM can't
provide?
- Is AES-CM is not suitable in a mobile, 3G environment or do have 3G
terminals have to implement both AES-CM as default and AES-f8 ?

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