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 …
[View More]successive block in the encoded ASN.1 value?
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.
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.
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?
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)lists.intel.com
[View Less]
Can anyone harmonize the various requirements/recommendations in H.235
regarding which ciphers and modes to support? I've tried to summarize
the various relevant passages from H.235, below. This text is from the
H.235v3 draft but v2 is similarly unclear. Regardless of what H.235
says, is there any concensus about which to actually support, e.g.,
DES/CBC as the base-level encryption scheme plus AES/EOFB on a forward-
looking basis?
The baseline security profile (D.6.1) says, "H.323 entities …
[View More]when
deploying the voice encryption security profile shall implement 56-bit
DES as the default encryption algorithm; they may implement 128-bit AES
or 168-bit Triple-DES while they may implement exportable encryption
using 56-bit RC2-compatible." This passage does not say whether to use
CBC or EOFB mode. It either means CBC because it is carried forward
from H.235v2 or it is not mode-specific.
Shall DES
May AES
May 3DES
May RC2
Text specific to Fast Connect (8.6.1) says, 'According to Annex D,
these capabilities should indicate support for 128-bit AES-CBC (OID
"Z3"), 56-bit RC2-compatible-CBC (OID "X"), should indicate support
for 56-bit DES-CBC (OID "Y") and may indicate support for 168-bit
Triple-DES-CBC (OID "Z"), 56-bit DES-EOFB (OID "Y1"), or 168-bit
Triple-DES-EOFB (OID "Z1"), RC2-compatible-EOFB (OID "X1"), DES-
EOFB (OID "Y1") or AES-EOFB (OID "Z2").'
Should AES CBC
Should RC2 CBC
Should DES CBC
May 3DES CBC
May DES EOFB
May 3DES EOFB
May RC2 EOFB
May DES EOFB (duplicate!?)
May AES EOFB
The voice encryption security profile (D.6.1.2) says, "In addition to
the CBC-encryption mode, H.323 entities may implement the EOFB
encryption mode." Does this mean that H.323 entities _should_ support
CBC but may support EOFB?
Should CBC
May EOFB
The voice encryption security profile (D.7) also says, "The audio
payload is encrypted using the negotiated encryption algorithm
("X", "Y", "Z3" or "Z") operating in CBC mode according to the
procedures described in section 11 and annex B of H.235 and the
ciphertext padding methods of Appendix I.1/H.235. The audio payload may
be encrypted using the negotiated encryption algorithm
("X1", "Y1", "Z1" or "Z2") operating in a stream cipher mode (EOFB)."
However, I dont know what "is" means, as in, "The audio payload is
encrypted using..." IOW, does it mean "shall," "should" or is it not
prescriptive at all?
Is RC2 CBC
Is DES CBC
Is AES CBC
Is 3DES CBC
May RC2 EOFB
May DES EOFB
May 3DES EOFB
May AES EOFB
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)lists.intel.com
[View Less]
Dear SG16 experts,
The subject document has been uploaded as follows:
http://standard.pictel.com/ftp/avc-site/0208_Ral/AVD-2259.zip
--
Best regards,
OKUBO Sakae
e-mail: okubo(a)giti.waseda.ac.jp
*******************************************************************
YRP Office
Global Information and Telecommunication Institute (GITI)
Waseda University
YRP Ichibankan 312 Tel: +81 468 47 5406
3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413
…
[View More]239-0847 Japan
GITI Headquarter
29-7 Waseda University Bldg. Tel: +81 3 5286 3831
1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832
169-0051 Japan
*******************************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)lists.intel.com
[View Less]
