No subject

[이심현]

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 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 6:16 PM
To:     ITU-SG16 at 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 at lists.intel.com

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