Encrypting session key

[Robert R. Gilman]

Paul-
I think the H.235 statement is a mistake.  It makes much more sense to treat the
update
just like the initial key distribution: use the negotiated shared secret, the
indicated
algorithm (which could be any algorithm supported by the parties), and the
provided
initialization vector(s), if any.  In any case, all this is contained in the
H235Key.sharedSecret, isn't it?  (Take a look at the ENCRYPTED() macro.)  The
statement
you quote would just require that the algorithmOID be the same as the media
encryption
algorithm - and even that is not necessarily a good idea, I think, so perhaps we
should
ask the editor to change it.
I've made a couple of specific comments in your message, below.
-Bob
----------------------------------------------------
Bob Gilman       rrg at avaya.com      +1 303 538 3868


Paul Long wrote:
>
> 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.
>
> 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?

The mode should be part of the algorithm OID in ENCRYPTED().

>
> IV
> For H.235v3, one clearly uses the IV specified in the new type,
> NewKeySyncMaterial.paramS. However, what does one do for v2? There
> doesn't seem to be any way to specify the IV for session-key
> encryption. 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.

This is defined in ENCRYPTED().paramS:

H235Key ::=CHOICE  -- this is used with the H.245 "h235Key" field
{
        secureChannel           KeyMaterial,
        sharedSecret                    ENCRYPTED {EncodedKeySyncMaterial},
        certProtectedKey                SIGNED { EncodedKeySignedMaterial },
        ...
}

ENCRYPTED { ToBeEncrypted } ::= SEQUENCE {
        algorithmOID            OBJECT IDENTIFIER,
        paramS                  Params, -- any "runtime" parameters
        encryptedData           OCTET STRING
} ( CONSTRAINED BY { -- Encrypt or Decrypt -- ToBeEncrypted } )

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

I'd suggest that we could add salt to the Params structure.

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

I'd suggest that padding method be part of the algorithm OID, and that we
shouldn't tie this to the media stream.  If we need to specify it explicitly,
then we should add it to Params.

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