H.235wht2 (and related H.2250) - Rem

Sengodan Senthil NRC/Boston sengodan at NASBPD01BS.NTC.NOKIA.COM
Fri Jan 23 18:38:24 EST 1998


Hi,

As I understand it, "RandomVal" and "ranInt" being restricted to 32 bits should not affect security if care is taken to change the key after a certain number of exchanges.

Random numbers are included to prevent replay attacks. If they were not included, then the GatekeeperId (or some known general ID) alone would be encrypted using the shared key, and an adversary could replay this encrypted GatekeeperId in the future without knowing the key. Including the random number prevents such a replay attack.

In most cases the random number generated by EPB is sent in plaintext to EPA. An adversary can maintain a table of random number and encrypted "random number + gatekeeperID". If the random number sent by EPB matches an entry with the adversary, he could launch a replay attack. Hence, it is important that the key should be changed at least before the random number sent by EPB repeats. Depending on the algorithm being used, it may be necessary to change the key prior to that in order to prevent other attacks, specifically known-plaintext attacks in this case.

So, it seems that 32 bits is sufficient. Moreover, 32 bits is a commonly chosen value for such purposes. For instance, the proposed authentication header extension for the IP header in TCP/IP has a 32 bit field for this purpose.

Regards,
Senthil

Senthil Sengodan
Nokia Research Center

 ----------
From: Mailing list for parties associ
To: ITU-SG16
Subject: Re: H.235wht2 (and related H.2250) - Remarks
Date: Friday, January 23, 1998 10:47AM


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 at mchp.siemens.de
|
| Otto-Hahn-Ring 6
| 81730 Muenchen
| __________________
| Germany
 -----------------------------------------------------------------------

 -----Original Message-----
From: ITU-SG16 [SMTP:ITU-SG16 at 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 at radvision.com
575 Corporate Dr., Suite 420            Tel:    201-529-4300 ext. 230
Mahwah, NJ 07430                        Fax:    201-529-3516



More information about the sg16-avd mailing list