Hi Paul,

thanks for your review of H.235v3. Let me try to answer your questions 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@icn.siemens.de | mailto:martin.euchner@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@PACKETIZER.COM] Sent: Monday, September 09, 2002 6:16 PM To: ITU-SG16@echo.jf.INTEL.COM Subject: Required/recommended ciphers in H.235?

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. MEU:> I hope that my answers do not let you continue believing that H.235 is unclear in these areas.

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?

MEU:> We have a definite agreement for H.235v2 what to support. For version 3, the add-ons (AES, EOFB) are a proposal on the table and are subject for discussion and change, yet we are currently in the phase to achieve consensus, until H.235v3 becomes stable.

I agree that the situation appears a bit complicated for the following reasons: H.235v2 defines just the 3 encryption algorithms: DES, RC2 and 3DES. DES is a shall implement, while 3DES, RC2 are may implement, where DES and RC2 are considered as exportable ciphers (in certain countries). H.235v3 adds AES as another may implement cipher.

The encryption cipher does not say which encryption mode (such as ECB, CBC etc) the cipher should actually operate in. Thus, the issue of the mode is a separate one. Note, that the operation mode is not crucial to exportability considerations. Simply speaking, H.235v2 only defines CBC encryption mode for each cipher. H.235v3 adds the EOFB mode as a further option (may). Due to the fact that there is just a single OID available, there is a distinct OID value assigned for each defined combination cipher + mode.

The baseline security profile (D.6.1) says, "H.323 entities 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

MEU:> This is correct and fully intentional. This referenced statement addresses the ciphers but not the modes. As I explained above, H.235v2 is not mode specific, but V3 further extends the capabilities without changing backwards compatibility.

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

MEU:> The duplicate is indeed an editorial copy & paste mistake. Thanks for pointing this out. Just remove either duplicate. This is a complete set that allows to run each cipher in CBC or in EOFB mode.

As editor, I'm a little bit concerned about the variety that arises (see also my contribution AVD-2243 "Considerations for discussion on fast start-based security capability negotiation"). I would love to hear opinions if all that variety is actually needed or if the EOFB mode is needed just for a particular (set of, which?) algorithm(s); e.g. EOFB only for AES??? I could imagine that some less frequently implemented ciphers might not need the EOFB mode. This is an area where I'm not certain if there is conscious consensus yet. Comments are highly appreciated!

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

MEU:> yes correct, that is the idea.

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 don't 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

MEU:> Good point. I agree that the "is" is bad language here. It was meant to mean "shall". I will file a change request if agreed.

Paul

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

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