Hello, security people,
Here are some comments on the last H.235 draft: They following relate to the authentication scheme in 10.3:
In 10.3: We think it would be more appropriate that the party that proves its identity send its own ID in the authentication token, rather that the ID of the authenticating party. In other words, in the diagrams, EP A would rather send a token containg generalID_A, rather than generalID_B, and vice versa. In Hash & Encryption-based authentication schemes - we propose to add the ID also in the clear part of the token, so that the authenticating party can know who to authenticate. There is an inconsistency between the CryptoToken defintion of H.235, and the one in H.225.0, (named CryptoH323Token). To settle all this, and also incorporate (1) & (2) above, we propose the following ASN.1 for that, based on the H.225.0 definition:
CryptoH323Token::= CHOICE { cryptoEPPwdHash SEQUENCE {
timeStamp TimeStamp, -- timestamp used in hash token HASHED { EncodedPwdCertToken ?- generalID set to ?alias? -- } }, cryptoGKPwdHash SEQUENCE { gatekeeperId GatekeeperIdentifier, -- GatekeeperID of GK generating hash timeStamp TimeStamp, -- timestamp used in hash token HASHED { EncodedPwdCertToken -- generalID set to Gatekeeperid -- } }, cryptoEPPwdEncr SEQUENCE { alias AliasAddress, -- alias of encrypting entity token ENCRYPTED { EncodedPwdCertToken ?- generalID set to alias --} }, cryptoGKPwdEncr SEQUENCE { gatekeeperId GatekeeperIdentifier, -- GatekeeperID of encrypting GK token ENCRYPTED { EncodedPwdCertToken ?- generalID set to gatekeeper ID --} },
cryptoEPCert SIGNED { EncodedPwdCertToken ?- generalID set to Gatekeeperid -- }, cryptoGKCert SIGNED { EncodedPwdCertToken ?- generalID set to alias -- }, cryptoFastStart SIGNED { EncodedFastStartToken }, nestedcryptoToken CryptoH323Token, ... }
Lastly, H.235 mentions nothing about the RAS Integrity Check mechanism specified in H.225.0. We think it is appropriate to specifiy it also in H.235.
LiorM
"EXT Lior Moscovici" Lior_Moscovici@VOCALTEC.COM writes:
Here are some comments on the last H.235 draft: They following relate to the authentication scheme in 10.3:
In 10.3: We think it would be more appropriate that the party that proves its identity send its own ID in the authentication token, rather that the ID of the authenticating party. In other words, in the diagrams, EP A would rather send a token containg generalID_A, rather than generalID_B, and vice versa.
ISO/IEC 9898-2 notes:
Distinguishing idenitifier B [generalID_B] is included in the token AB [token sent from A to B] to prevent the re-use of TokenAB on entity A by an adversary masquerading as entity B. ... Their [generalID] inclusion is made optional so that, in environments where such attacks cannot occur, one or both may be omitted.
I can imagine some scenarios, where such attacks are possible. Let's suppose there are two gatekeepers, B and C, which use the same passwords to authenticate terminals. Terminal A sends an authorisation token to B. Now, if the generalID_B is not included in the token, an eavesdropper can send the same token to C.
Pekka Pessi
participants (2)
-
Lior Moscovici -
Pekka Pessi