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

Report of the Sunriver meeting APC-1327
by Sakae Okubo 25 Sep '97

25 Sep '97

Dear SG16 colleagues, With the lack of comments, I have placed APC-1327 at the 9709_Sun directory as "confirmed by the participants". If you have found anything wrong, please advise me. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

Directory 9801_Gen at the ftp site
by Sakae Okubo 25 Sep '97

25 Sep '97

Dear SG16 colleagues, As suggested at the Sunriver meeting, I have created the subject directory at the GCL ftp site. This is for the moment to place white contributions for decision at the January 1998 meeting of SG16. Later other files will also be placed here such as input and output TDs. Currently the followings are available; H222AM34.doc, H262AM34.zip, H321v2wh.zip. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

Re: Corrections for H.225.0 V2.
by Euchner Martin ZT IK 3 25 Sep '97

25 Sep '97

Dear Glen, Attached is a word document that shows the additions and changes I made to the H.225 ASN.1. Could you please review and let me know if it is now correct, or what needs to change? I need to send the document in today (Thursday), so please reply as soon as possible. Perhaps you can help me understand something. The GRQ has an integrity field (SEQUENCE OF IntegrityMechanism) which I assume is used by the sender to indicate the algorithms available to the sender. meu>: That's right. Sender and receiver negotiate during GRQ/GFC whether to apply integrity on RAS messages and if yes, which integrity mechanism they choose; see IntegrityMechanism (digital signature, ISO9797, HMAC-xxx or non-standard). The ICV includes an algorithmOID (OBJECT IDENTIFIER), which I'm guessing indicates the algorithm used to compute the integrity check value. But, it looks to me that the possible algorithms under IntegrityMechanism are not represented in algorithmOID. For example, how can I represent hMAC-MD5 or nonStandard in ICV? Can you explain this to me? meu>: This is not quite correct. The algorithmID within the ICV structure is only used when the digital signature is applied as integrity mechanism. In this case, the algorithmOID tells the receiver by which digital signature algorithm the sender has computed the enclosed digital signature (e.g. RSA or DSS and applied hash functions etc.). However, this algorithmID is not used at all when the ICV is computed using symmetric techniques such as the HMAC methods or ISO9797. As both involved entities have agreed already on the integrity mechanism during GRQ/GCF there is no further need to indicate the applied integrity method within each RAS message; thus, it is not possible to change the integrity mechanism between RAS messages on the same RAS channel. I reviewed also the attached Word document which you sent me and recommend the following change to the ICV structure: I made the following changes: 1.) replaced the dash by a blank between OBJECT and IDENTIFIER 2.) replaced icv by signature in the comment. 3.) replaced the underscore _ by a blank between BIT and STRING. ICV ::= SEQUENCE { algorithmOID OBJECT IDENTIFIER, -- the algorithm used to compute the signature icv BIT STRING -- the computed cryptographic integrity check value -- or signature } That's all. I hope this helps and clarified your questions and allows you to complete and close H.225.0 V2! I will post this message also to our ITU-T reflector; however as round-trip time is very long - about one day for me - you will also get a direct mail from me which should get through much faster. Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 e-mail: Martin.Euchner(a)mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

1 0

"flowControlToZero message?"
by Paul Long 25 Sep '97

25 Sep '97

7.3.2/H.245v3 mentions the FlowControlToZero field of the H2250LogicalChannelAckParameters type and a "flowControlToZero message" (see quote below). However, I cannot find a definition for such a message in the H.245 ASN.1 syntax. Is this _not_ an H.245 message, has it just not been defined yet, or should this be a reference to the _FlowControl_ message with scope set to logicalChannelNumber? Regardless of the answer, this needs to be explained better in the Recommendation. "FlowControlToZero indicates whether the transmitter is allowed to start transmitting on the logical channel. If set to true, it indicates that the transmitter should not transmit on the logical channel until receiving a subsequent flowControlToZero message allowing it to do so. If set to false, or absent, the transmitter is allowed to begin transmitting immediately the channel is established." -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 1

Whither userInputSupportIndication?
by Paul Long 25 Sep '97

25 Sep '97

With the addition of UserInputCapability to H.245v3, the H.245v2 userInputSupportIndication choice of UserInputIndication is redundant and could cause interoperability problems due to the resulting ambiguity. Since H.245v2 is Decided, we cannot remove userInputSupportIndication from the H.245 ASN.1 syntax. Therefore, how shall we resolve there being two ways to signal whether a terminal is able to transmit the nonStandard, basicString, iA5String, or generalString forms of the alphanumeric choice of UserInputIndication? We could just "ignore" the problem and deprecate the use of the userInputSupportIndication choice either formally, i.e., written down, or informally. Or we could hope that referencing Recommendations do not require or allow userInputSupportIndication. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 0

Corrections for H.245V3
by Euchner Martin ZT IK 3 24 Sep '97

24 Sep '97

Dear Mike, I checked H.245 V.3 from a security point of view and found out that the following issues have to be corrected: Subsection Conference Response definitions is missing definition of ReturnSig which should be as follows: ReturnSig ::= SEQUENCE { alias AliasAddress, responseRandom RandomVal, requestRandom RandomVal OPTIONAL, certificate TypedCertificate OPTIONAL - requested certificate } EncodedReturnSig ::= TYPE-IDENTIFIER.&Type (ReturnSig) The following definition seems not to be used by any H.245 ASN.1 and looks rather redundant; thus it should be removed: ChallengeString ::=OCTET STRING (SIZE(8..16)) Please incorporate these changes to the text. Thank you. Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 e-mail: Martin.Euchner(a)mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 e-mail: Martin.Euchner(a)mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

1 0

White contribution for H.321 v2
by Sakae Okubo 24 Sep '97

24 Sep '97

Dear Mr. Gates, I have reviewed your three documents contained in H321v2.zip and slightly modified them as follows: 1) H321v2.doc - clean version I have added a cover sheet for the white contribution with Rapporteur as the source and Editor as the contact point. The draft Recommendation is kept intact except for adding 5.9 in CONTENT. New file is named as H321v2wh.doc. 2) H321dlta.doc - revised version with change marks I tried to remove redundant parts such as striking out the original text and adding a new text (like Section 3 Definitions and Abbreviations) by using the material in the list of changes. I also tried to remove the change marks for unchanged figures. I found new 5.9 was missing in CONTENTS. New file is named as H321v2wc.doc. 3) H321chng.doc - list of changes - new 5.9 has been added in CONTENTS. - replacement of Figure 3 has been added. - renumbering of the items New file is named as H321dltr.doc. Updated three files and their zipped file (H321v2wh.zip) are plcaed in the Incoming directory of the GCL ftp site. I would appreciate if you have time to take a look at it. In any case I will send it to Geneva tomorrow (25th, Tokyo time). Could you please help TSBEDH if anything is wrong as I am going to travel from next Friday for a week without access to the Internet? Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

Corrections for H.235
by Euchner Martin ZT IK 3 24 Sep '97

24 Sep '97

Dear Jim, all the following comments concern the H.235 white paper on the reflector. I tried to check the remaining stuff very quickly in the document and found the following items: 1. Page 7: goal no. 7 should end with H.235. 2. page 12: device is missing in the sentence ... not simply the physical device. 3. page 14: Section 6.6 does not mention that MCUs as well as intermediate GW/GKs are considered as trusted elements. Thus, the reference in section 9.1 is misleading and should point at least to section 3 in the appendix A instead. Why don't you include that section also to section 6.6? 4. Page 17: Section 10.2: Headline should read Diffie-... instead of Diffe. 5. Page 17: Section 10.2: Figure A: the request is missing the SeqNum and should look like ... XOR randomb XOR SeqNum ... 6. page 19: Section 10.3.4: I would change exchanged to assigned in the 2nd sentence with would read then: This protocol is based on ISO 9798-3, (5.2.1), it is assumed that an identifier and associated certificate are assigned during subscription. 7. page 19: Section 10.3.4: The figure should allow also optional certificate exchange. 8. Page 22: In AuthenticationMechanism one-way has to be deleted in the comment - Diffie-Hellman. 9. certificate key protection stuff within H.245 seems not to be complete, this needs some more inspections..... Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 e-mail: Martin.Euchner(a)mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

1 0

Re: H.235 Draft
by Corey Gates 24 Sep '97

24 Sep '97

Jim, Some mostly editorial comments on the H.235 Draft: - (Page 12) Section 6.2, 2nd paragraph, 3rd sentence ends with "...not simply the physical."; do you mean to say "physical terminal"? I'm not sure. - (Page 13) Section 6.2.1, 2nd paragraph, 1st sentence "... requires the endpoints..." should be changed to "...the endpoints are required..." - (Page 14) Section 6.6, 1st paragraph, last sentence: remove the "," between "...an element" and "is the confidence...". - (Page 16) Section 8.4, the last sentence is enclosed in braces; is there a reason for this? It seems that the statement about the MC is valid and should be included in the text. This is re-stated in section 9.2 I believe. - (Page 16) Section 8.5, 3rd paragraph: It seems that this should only apply when the H.245 channel is secure; in fact the document allows for the encryption key to be passed in other places beside the OpenLogicalChannelAck. Perhaps we need to add a sentence saying that "When the H.245 channel is operated in secure mode..." or something like that. Section 11.1appears to fill this out. - (Page 17) Section 10.2, Figure A, Phase 2: Shouldn't this be a cryptoToken, because it is encrypted via the DH key? Maybe I don't understand the token usage correctly. Also, should we include a Note descibing the meaing of { }E DH-secret ? The other figures seem to have note to this effect. Finally, the last sentence of this sections indicates that EPB knows GeneralIDa, but I believe this will only be true if Phase 1 includes the optional cryptoToken. - (Page 21) Section 11.1, last bullet point of last paragraph: encryptionUpdate should be in bold type. - (Page 22) Annex A: Is there a reason why ChallengeString is limited to only 16 OCTETs? It seems that this may want to get larger in the future. Also, do the BIT STRINGS in the DHset need to have MSB/LSB ordering specified? A comment would probably suffice and clear up future implementation problems. - (Page 32 and 38) Appendix A to D: Should these be numbered Appendix I to IV so as not to be confused with Annexes? Corey Gates corey(a)fvc.com Tel: +1.408.567.7214 Fax: +1.408.988.7077

2 1

Corrections for H.225.0 V.2
by Euchner Martin ZT IK 3 24 Sep '97

24 Sep '97

Dear Glen, I just checked H.225.0 V.2 as H.235 no longer contains security ASN.1. Thanks for including the ICV fields from APC-1271 in all the RAS messages. Unfortunately, you forgot to include the following ASN.1 signaling elements shown below which are necessary to signal the integrity mechanism to be used during the GRQ and GCF to the recipient. Sections 7.8.1 and 7.8.2 about GRQ and GCF should include the following description: integrity - indicates to the recipient which integrity mechanism is to be applied on the RAS messages. All the following stuff goes into section 15 - Annex H: EncryptIntAlg ::= CHOICE { -- core encryption algorithms for H.225.0 message integrity nonStandard NonStandardParameter, isoAlgorithm OBJECT IDENTIFIER , -- defined in ISO/IEC 9979 } NonIsoIntegrityMechanisms ::= CHOICE { -- HMAC mechanism used, no truncation, tagging may be necessary! hMAC-MD5 NULL OPTIONAL, -- MD5 as hash function hMAC-iso10118-2-s EncryptIntAlg OPTIONAL, -- according to ISO/IEC 10118-2 using -- EncryptIntAlg as core block encryption algorithm (short 64-bit MAC) hMAC-iso10118-2-l EncryptIntAlg OPTIONAL, -- according to ISO/IEC 10118-2 using -- EncryptIntAlg as core block encryption algorithm (long 128-bit MAC) hMAC-iso10118-3 OBJECT IDENTIFIER OPTIONAL, -- according to ISO/IEC 10118-3 -- using OID as hash function (OID is SHA-1, RIPE-MD160, RIPE-MD128) } IntegrityMechanism ::= CHOICE { -- for H.225.0 RAS message integrity nonStandard NonStandardParameter, digSig NULL OPTIONAL, -- indicates to apply a digital signature iso9797 OBJECT IDENTIFIER OPTIONAL, -- according to ISO/IEC 9797 using OID as -- core encryption algorithm (X-CBC MAC) nonIsoIM NonIsoIntegrityMechanism } Thus GRQ and GCR should read as follows (integrity entry added): GatekeeperRequest ::= SEQUENCE --(GRQ) { requestSeqNum RequestSeqNum, protocolIdentifier ProtocolIdentifier, nonStandardData NonStandardParameter OPTIONAL, rasAddress TransportAddress, endpointType EndpointType, gatekeeperIdentifier GatekeeperIdentifier OPTIONAL, callServices QseriesOptions OPTIONAL, endpointAlias SEQUENCE OF AliasAddress OPTIONAL, ..., alternateEndpoints SEQUENCE OF Endpoint OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL, cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, integrity SEQUENCE OF IntegrityMechanism OPTIONAL, authenticationCapability SEQUENCE OF AuthenticationMechanism OPTIONAL, algorithmOIDs SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, integrityCheckValue ICV OPTIONAL } GatekeeperConfirm ::= SEQUENCE --(GCF) { requestSeqNum RequestSeqNum, protocolIdentifier ProtocolIdentifier, nonStandardData NonStandardParameter OPTIONAL, gatekeeperIdentifier GatekeeperIdentifier OPTIONAL, rasAddress TransportAddress, ..., alternateGatekeeper SEQUENCE OF AlternateGK OPTIONAL, authenticationMode AuthenticationMechanism OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL, integrity SEQUENCE OF IntegrityMechanism OPTIONAL, cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, algorithmOID OBJECT IDENTIFIER OPTIONAL, integrityCheckValue ICV OPTIONAL } I'm sorry for the late discovery. Please include the above changes to the document text. Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 e-mail: Martin.Euchner(a)mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

1 0