comments inline
> 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:
I wasn't distinguishing between the initial and subsequent key
distributions--my questions apply equally to them both because they
ultimately use the same type, EncryptionSync, and presumably posses the
same semantics.
> 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.)
No, H235Key.sharedSecret is apparently lacking in this regard. See
below.
> 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 see no reason to use a different encryption algorithm for media
privacy and private key distribution. I'd like this to be as simple as
possible. Therefore, for key distribution, we should try to exploit the
existing media-privacy codepoints and semantics wherever possible.
> I've made a couple of specific comments in your message, below.
> -Bob
> ----------------------------------------------------
> Bob Gilman rrg(a)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().
Yeah, I know. I was just wanting to make sure that one uses the
indicated mode in exactly the same way as for media. I guess you are
saying that the answer is, yes.
> > 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 } )
Okay, I see now. I just wish it were not defined as part of an optional
profile.
D.7.2: "paramS: set to the initial value. iv8 holds a random 64-bit
block bit pattern that the initiator generates. This field is not used
for the CBC mode and is set to NULL."
Hmmm... CBC uses an IV, so how does one signal it if not via paramS?
> > 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.
But it would be passed in the clear, wouldn't it? Seems like we're
going to have to derive it somehow. For example, assume that the master
salt has the same value as the master key. That's better than passing
it in the clear or using a static value, isn't it?
> > 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.
How about just always use zero padding when encrypting session
encryption material? Is there any reason at all to use something more
flexible?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)lists.intel.com
