Re: H.235wht2 (and related H.2250) - Rem
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@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
Hi,
Here are our (Sengodan Senthil [sse], Sari Kuisma [SKu] and Pekka Pessi [PPe]) comments on the H.235 text.
I'll send a MS Word 95 file containing the comments in a separate message.
Regards, Pekka Pessi
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Summary, second paragraph, "the network does not provide a secure service.":
[sse1] IPSEC provides network security. Since IPSEC is one of the proposed ways of achieving authentication/confidentiality in this Recommendation, we should probably also add that "The Recommendation also has provisions for incorporating any available security provided by the network (such as IPSEC)."
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
"3. Definitions", first paragraph:
[PPe2] It might be useful to utilize an authoritative source to define the general terminology. The capitalization of terms changes from term to term.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Definition of "certificate":
[PPe3] In other words, the certificate means a certified public key. Would it be useful to refer to public keys instead of certificate, then?
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Definition of "confidentiality":
[PPe4] confidentiality is usually used as synonym of privacy
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Definition of "cryptographic algorithm":
[SKu5] The definition here does not include the hash functions (MD5, SHA).
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Definition of "encipherment", instead of words "data unreadable":
[sse6] Use "information unreadable" or "data unintelligible"
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Definition of "integrity":
[sse7] Integrity also includes "detecting any unauthorized alteration"
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Definition of "privacy": (see definition of confidentiality)
[SKu8] This is usually used as a synonym of confidentiality.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Definition of "private channel":
[SKu9] It might be useful to spell out that a private channel uses encryption and optional authentication procedures agreed on the secure channel.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 6.1, item II, instead of words "exchanging certificates" [SKu10] "...using proper public-key authentication method..."
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 6.1, item VI, words "exchanged certificates":
[SKu11] Again, see previous comment concerning term "certificate".
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 6.2 (authentication), first paragraph, second sentence:
[sse12] This implies that exchange of certificates is not based on a shared secret. In Section 10.1, certificates are included under subscription based which is defined as having a prior shared secret. They are inconsistent statements. It seems to me that the former is right, while the latter is not. See comment in section 10.1.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Second paragraph, second sentence:
[SKu13] In order to authenticate claimant (the presenter of a certified public key), the claimant must sign something provided by the verifier or the generalID of the verifier. The definition of verifier should be added to the list of definitions.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
4th sentence, words "Digital Certificates":
[SKu14] This should probably be "digital signatures".
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
5th sentence ("In general, certificates give some assurance to the verifier that the presenter of the certificate is who he says he is."):
[PPe15] This sounds strange. I would say that we would be protected against man-in-the-middle attack only if we know who the correspondent is.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 6.2.1:
[sse16] Add subsection 6.2.2 for "shared secret schemes", and subsection 6.2.3 for "Other security protocols." In 6.2.2, we need to state that the Recommendation does not specify how the shared secret is established and managed.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 6.2.1, first paragraph, on "distribution":
[sse17] Isn't distribution done by the claimant by sending the certificate along with the digital signature to the verifier?
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Second paragraph, second sentence ("The exchange of public key certificates alone does not protect against man in the middle attacks"):
[SKu18] ...does not provide any security at all.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 6.4, first paragraph, first sentence, word "privacy":
[SKu19] security (???)
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 6.4, first paragraph, third sentence, words "encryption keys":
[SKu20] ...encryption parameters, including keys,...
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 6.5, last paragraph, second sentence ("Transport specific header information shall not be encrypted."):
[PPe21] Does this include the RTP headers, too?
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 10.1, ("introduction to authentication signalling and procedures"), second sentence:
[SKu22] The first method is asymmetric Diffie-Hellman key exchange. It includes an optional public key based authentication, and it requires no prior direct contact between entities.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Fourth sentence:
[sse23] There is an important difference between password and certificate based schemes as described here. In the password based scheme, EPB needs to know the password that EPA uses by means other than from EPA. However, in certificate based schemes, EPB could find the public-key of EPA directly from EPA by receiving the public key certificate from EPA. Hence, password based schemes (as described here) requires prior contact between EPA and EPB, but certificate based schemes do not. This difference should be highlighted
Moreover, there seems to be an inconsistency in the description of "subscription based" in this section and in section 6.2. See comment there.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 10.2, "Diffie-Hellman with optional Authentication":
[PPe24] It should be made clear that the procedure here is not authentication but a key-exchange (unless optional authentication is included). Why we are including the random number random_b and the time_a etc (certainly, it does not protect against a man in the middle). Is this a standard ISO or IETF protocol? The first generalID_a should probably be generalID_b. (The modulus and base should be defined for the Diffie-Hellman.) How the optional authentication procedure differs from the authentication presented in the subsection 10.3.4? What is implied by the use of clearTokens in the phase 2?
The first generalID_a should probably be generalID_b. The modulus and base should be defined for the Diffie-Hellman. How the optional authentication procedure differs from the authentication presented in the subsection 10.3.4?
[SKu25] The meaning of the generalID should be defined somewhere.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 10.3.2, case "if the password length < N":
[SKu26] It might be more useful reuse password bytes instead of padding.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 10.3.2, "Password with symmetric encryption":
[SKu27] The first exchange of the generalIDs is not part of the authentication mechanism (presented in ISO 9798-2). It should be noted that each endpoint generates their own timeStamp.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 10.3.3, "Password with hashing":
[SKu28] The first exchange of the generalIDs is not part of the authentication mechanism (presented in ISO 9798-2). It should be noted that each endpoint generates their own timeStamp. The generalID and timestamp values should be included in the ClearToken, but not the password. J Annex A suggests that all information in the cryptoHashedToken is included in clear text as hashedVals ClearToken.
We suggest that the CryptoToken is written as
CryptoToken[...timeStamp_a, generalID_b, (,timeStamp_a, generalID_b, password)Hash...]
where (foo)Hash means only the hash value of foo. Another possibility is to use notation
CryptoToken[...(,timeStamp_a, generalID_b)Hash_password ...]
where (foo)Hash implicitly includes the cleartext foo in the CryptoToken.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 10.3.3, "Password with hashing", note 2:
[sse29] Instead of using a hash function (such as MD5 or SHA-1) on (timeStamp, generalID, password), a better approach is to use HMAC which is defined in RFC2104. The former approach, generally referred to as keyed-xxx (where xxx is a hash function), is somewhat inferior to HMAC-xxx. The IETF also favors HMAC-xxx.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Subsection 10.3.4, "Certificate based with signatures":
[SKu30] The first exchange of the generalIDs is not part of the authentication mechanism (presented in ISO 9798-3). It should be noted that each endpoint generates their own timeStamp.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Annex A:
[PPe31] It should be noted what kind of transfer encoding is to be used, e.g., within h235Key. The usage of the ASN.1 types should be specified somewhere in a very detailed way. How a type is signed? How it is encrypted? How a hash is generated? How we can generate a keyed hash?
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Annex B, section 1, second paragraph, words "usage of TLS, IPSEC":
[sse32] An important difference between TLS and IPSEC should probably be pointed out. TLS is usually application coupled (i.e., built into the application), while IPSEC is usually network coupled (i.e., built into the operating system). This could possibly be pointed out by incorporating a subsection for TLS in the "Implementation Examples" section, as has been done for IPSEC.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Annex B, section 2, second paragraph, the term "H.225.0 channel":
[PPe33] What? A Q.931channel, probably?
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Annex B, section 3, first paragraph, first sentence, words "will follow":
[PPe34] Will *not* follow?
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Annex B, section 3, footnote 1:
[PPe35] This footnote is indecipherable. The RTP uses underlying IP packet delivery, a UDP packet with missing fragments is never presented to the application (i.e. the RTP protocol).
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Annex B, section 3, item A "Initialization vectors", sentence "It should be noted that the IV generated in this manner may produce a key pattern that is considered 'weak' for a particular algorithm":
[PPe36] This does not seem to make sense. The IV is not a key, or a key pattern. Are there really weak initialization vectors? I think that here should be stated that the initial timestamp and sequence number should be generated by a cryptographically strong random number generator.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Annex B, subsection 4.1, words "(EPA and EPB)":
[sse37] Delete braces
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
participants (2)
-
Pekka Pessi -
Sengodan Senthil NRC/Boston