September 2002 - sg16-avd - lists.packetizer.com

None
by 이심현 13 Sep '02

13 Sep '02

OK

1 0

Re: Required/recommended ciphers in H.235?
by Euchner Martin ICN M SR 3 12 Sep '02

12 Sep '02

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(a)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(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

More Mail List Troubles? Please Ignore This Test Message.
by Meyer, Greg W 11 Sep '02

11 Sep '02

Hello: We've seen some anomolies again in the ITU-SG16 mail list and this message is a test to see if it's working OK. Greg Meyer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Contributions to the SG16 meeting (15-25 October 2002)
by OKUBO Sakae 10 Sep '02

10 Sep '02

Dear Q.D,F,G,2-5/16 experts, I have created a new directory at the avc-site: ftp://standard.pictel.com/avc-site/0210_Gen or http://standard.pictel.com/ftp/avc-site/0210_Gen This is for the documents input to and output from the SG16 October meeting in Geneva. Please post your delayed contributions and TDs at the following place and make an announcement at the reflector <itu-sg16(a)lists.intel.com>: ftp://standard.pictel.com/avc-site/Incoming Please note that the files stored there are those provided voluntarily by the contributors for early review of the input/output documents by the experts. Since the SG16 meeting is an official ITU-T meeting and managed by TSB, you must send your documents to TSB-EDH. The meeting documents will be made available at the ITU TIES site for ITU-T members. The PictureTel site is NOT intended for mirroring the ITU TIES site, it is functioning to assist the study of experts. -- 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 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

1 0

Re: Encrypting session key
by Paul Long 09 Sep '02

09 Sep '02

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

1 0

Encrypting session key
by Paul Long 09 Sep '02

09 Sep '02

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

2 1

Required/recommended ciphers in H.235?
by Paul Long 09 Sep '02

09 Sep '02

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

1 0

Raleigh meeting report AVD-2259
by OKUBO Sakae 05 Sep '02

05 Sep '02

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

1 0