More H.235 remarks
Pekka Pessi
Pekka.Pessi at research.nokia.com
Sun Jan 25 18:15:11 EST 1998
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<---
More information about the sg16-avd
mailing list