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@fvc.com Tel: +1.408.567.7214 Fax: +1.408.988.7077
Corey,
Thanks for your detailed review of the document. I have incorporated all of your comments except the two as listed below.....
jimt.
At 05:58 PM 9/23/97 -0700, you wrote:
Jim,
Some mostly editorial comments on the H.235 Draft:
[SNIP]
- (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.
The key is based in the OLC(A) whether the H.245 channel is secured or not. If the channel is in the 'clear' then the media session key is protected within the message itself. The algorithm and encryption key material (used to protect the media key) may be derived outside the H.245 Control channel itself. For example we might have opened an H235Control logical channel (in a normal, clear H.245) and on _this_ logical channel run IPSEC - establish authenticity and generate key material to be used when passing the media session keys......
- (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.
Actually the intent _was_ to pass it in the 'clearToken' field. This allows simple encoding (without using the parameterized types). Since the values that is encrypted does not depend on its ASN.1 representation, we can get away with this. The idea was to allow Diffie-Hellman to occur with the least complexity......
EPB _may_ know GeneralIDa if it is passed in the cryptoToken, but it might also know it from the source transport address, or some other means.....
************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga@ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************
participants (2)
-
Corey Gates -
Jim Toga