hello security guys,

you wrote: 1. The fields "RandomVal" and "ranInt" are defined as unconstrained INTEGERs. Is there a specific reason for that? It is more accurate to define a range for them: for example (0..4294967295) .

RandomVal and ranInt act as a challenge during the authentication protocols. Restricting these fields to 32 bits as proposed drastically reduces obtained security. Just to note, that in this case with 32 bits, exhaustive search on the challenge is easy by todays computers: thus replay attacks would be possible. That's why the randomVals and challenges are defined as arbitary integers: to make such crypto attacks infeasible. Therefore the spec should stay as it is.

you wrote: 4. ALGORITHM-IDENTIFIER is defined and never used.

As far as I remember this Algorithm-Identifier is obsolete and was replaced by an ObjectIdentifier.

Martin Euchner.

----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

-----Original Message----- From: ITU-SG16 [SMTP:ITU-SG16@mailbag.jf.intel.com] Sent: Donnerstag, 22. Januar 1998 17:57 To: ITU-SG16 Subject: H.235wht2 (and related H.2250) - Remarks

Hello, Jim!

I summarize below our remarks and questions regarding the ASN.1: 1. The fields "RandomVal" and "ranInt" are defined as unconstrained INTEGERs. Is there a specific reason for that? It is more accurate to define a range for them: for example (0..4294967295) . 2. In the definition below, what is the meaning for SEQUENCE containing NULL field? May be it is just a mistake: SEQUENCE instead of CHOICE?

-- signing algorithm used must select one of these types of parameters -- needed by receiving end of signature.

Params ::= SEQUENCE { null NULL, -- no value needed ranInt INTEGER OPTIONAL, -- some integer value iv8 IV8 OPTIONAL, -- 8 octet initialization vector ... }

3. The NonStandardParameter is locally redefined. Its meaning is a subset of the structure of the same name from H.225.0. Could we use the H.225.0 definition, instead of redefining it once again? 4. ALGORITHM-IDENTIFIER is defined and never used. 5. What is the reason for using the definitions of type "TYPE-IDENTIFIER.&Type" for single type only. For example: EncodedGeneralToken ::= TYPE-IDENTIFIER.&Type (ClearToken) -- general usage token Means EncodedGeneralToken ::= ClearToken -- general usage token

6. According to X.680, in the definitions of type "(WITH COMPONENTS {...," , it should be stated for each field what constrain is applied to it:

PresenceConstraint ::= PRESENT | ABSENT | OPTIONAL | empty

"empty" is syntactically right, but doesn't add any meaning in our case.

For example: The following statement

PwdCertToken ::= ClearToken (WITH COMPONENTS {..., timeStamp, generalID })

doesn't provide any additional information to already defined:

ClearToken ::= SEQUENCE -- a `token' may contain multiple value types. { timeStamp TimeStamp OPTIONAL, password Password OPTIONAL, dhkey DHset OPTIONAL, challenge ChallengeString OPTIONAL, random RandomVal OPTIONAL, certificate TypedCertificate OPTIONAL, generalID Identifier OPTIONAL, nonStandard NonStandardParameter OPTIONAL, ... }

Shouldn't it have been explicitly stated as PRESENT?

7. The two above remarks (5 and 6) apply to H.225.0 as well. Look for: FastStartToken ::= ClearToken (WITH COMPONENTS {..., timeStamp, dhkey, generalID -- set to 'alias' -- }) EncodedFastStartToken ::= TYPE-IDENTIFIER.&Type (FastStartToken)

Thank you, Orit Levin RADVision Inc. E Mail: orit@radvision.com 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 Mahwah, NJ 07430 Fax: 201-529-3516