Encrypting session key

[Euchner Martin ICN M SR 3]

Paul,

thanks once more for your review of H.235V3. You may find my answers in the
usual style in-lined below.


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:Martin.Euchner at icn.siemens.de
|                                mailto:martin.euchner at ties.itu.int
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany
-----------------------------------------------------------------------

 -----Original Message-----
From:   Paul Long [mailto:plong at PACKETIZER.COM]
Sent:   Monday, September 09, 2002 5:25 PM
To:     ITU-SG16 at echo.jf.INTEL.COM
Subject:        Encrypting session key

H.235 says, "The session key encryption algorithm is the same as the
negotiated media encryption algorithm." At the very least, this of
course means that one uses the same cipher; however, there are some
important details that this statement overlooks, i.e., mode, IV, salt,
and padding. I assume that the guiding principle is to treat the ASN.1
encoded value as much like an RTP payload as possible.

MEU:> I'm not certain if that is really a non-stated principle in this case.


Mode
Does one use the same mode as media and therefore the same block
processing for each successive block in the encoded ASN.1 value?

MEU:> Yes, that is the intention. See for example the statement in H.235V3
section 8.6.1 "The negotiated encryption algorithms and their modes of
operation for the media stream encryption will be used also for secure
distribution of the session key. The encryption algorithm for encryption of
the media key shall operate in the same chaining mode as the media
encryption algorithm".

IV
For H.235v3, one clearly uses the IV specified in the new type,
NewKeySyncMaterial.paramS.
MEU:> That's correct.

However, what does one do for v2? There
doesn't seem to be any way to specify the IV for session-key
encryption.

MEU:> Don't be afraid that you can't find a direct counterpart for
NewKeySyncMaterial.paramS in version 2. H.235 Version2 works slightly
differently, namely:
H235Key.sharedSecret carries the params as part of the ENCRYPTED{}
operation/macro; see also section D.7.2. I would like to note that I should
add some text in that section, that describes the v3 NewKeySyncMaterial
fields; to be completed....

I suppose one could derive it from the session key similar
to how SRTP derives stuff from the master key. For example, IV =
session key. Maybe this should go in the IG.

MEU:> No, no, no. This has nothing to do with SRTP. We are considering key
management here. Everything should be there for signalling the IV.

Salt
This is a tough one. One could have used the same salt being signaled
for media, but it is of course encrypted! Therefore, if the mode for
encrypting media is EOFB, which uses a salt value, and one is supposed
to use the same "encryption algorithm" for encrypting the session key
as encrypting media, what salt value does one use? An implied salt
value of all zeros would work, but this is not written down anywhere.

MEU:>

Paul, your observation is true. At present, v3 provides just a salt for the
media part, but does say anything about a salt for the purpose of key
distribution. This should indeed be clarified in H.235v3.

My proposal is just as simple, namely to state that a "NULL salting key"
(i.e. no salting key effectively) shall be used for encryption of the
session key and for encryption of the salting key. Thus, with the "NULL
salting key" that does not get signaled, the EOFB mode becomes actually the
standard OFB mode.

This is possible when assuming or ensuring that the session key and the
(media) salting key are random; then the ciphertexts are not susceptible to
known-plaintext attacks anyway.

NewKeySyncMaterial      ::= SEQUENCE
{
        generalID                               Identifier, -- peer terminal
ID
        algorithmOID                    OBJECT IDENTIFIER, -- encryption
algorithm
        paramS                          Params, -- IV
        encryptedSessionKey             OCTET STRING, -- encrypted session
key
        encryptedSaltingKey             OCTET STRING OPTIONAL, -- encrypted
salting key for media
        ...
}

Notes:

The session key distribution/key update protocol for the EOFB mode would
look like

A->B: IDa, IV, ENC_MK,IV,0(K), ENC_MK,IV,0(KS).

Where
IDa is the generalID of the source,
IV is the initial value/vector
ENC_M,I,0(K) mean EOFB encryption of plaintext K using key M, initial
value/vector I and a NULL salting key.
KS is the salting key for the media
K is plaintext session key.

If felt useful, I would like to add such a diagram to H.235v3.

Padding
This is the toughest to translate from media to session-key encryption.
This is the overall H.235 statement as to what kind of padding to
perform on media: "Two methods are available to handle packets whose
payload is not a multiple of blocks: 1) Ciphertext Stealing for ECB and
CBC; Zero pad for CFB and EOFB. 2) Padding in the manner prescribed by
[RTP] (Section 5.1)." Since a session key isn't an RTP packet, we can
eliminate #2. Therefore, #1 says to use zero padding for EOFB and
ciphertext stealing for CBC. Is that how we handle padding when
encrypting the session key?

MEU:> I guess that your issue mostly is due to some missing information
(that might be stated somewhere in the text, if you want).
For DES and AES128 there is no need for padding as the key always fits into
one or a few blocks.



Paul

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com