Douglas,
thanks a lot for the detailed explanation. I'm quite convinced now that the substitution method really works without the versioning drawback of the emptying method.
As I do not have a clear feeling what the other people think about this approach; I added your substitution method as proposal to the Annex J profile for the time being. Discussion should resolve which way to go....
Regards,
Martin.
-----------------------------------------------------------------------
| Dipl.-Inf. …
[View More] Phone: +49 89 636-46201
| Martin Euchner Fax : +49 89 636-48000
| Siemens AG
| ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de
| Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html
| Otto-Hahn-Ring 6 Internet: http://www.siemens.de
| D-81730 Muenchen
| __________________
| Germany
-----------------------------------------------------------------------
-----Original Message-----
From: Douglas Clowes [SMTP:dclowes@OZEMAIL.COM.AU]
Sent: Monday, September 20, 1999 11:55 PM
To: ITU-SG16(a)mailbag.cps.intel.com
Subject: Re: Security - H.235 message integrity
Martin,
Firstly, I hope that the mechanism for encoding the HMAC is well
understood, and the reason for using HMAC-SHA1-96 (RFC-2404).
Secondly, the decoding:
The message which arrives is a bucket of bits, inside a TPKT. (It would be
nice to have something in the TPKT to tell us whether the message contained
is encrypted, but it doesn't. :-( ) If it's encrypted, assume you can tell
and decrypt it. This is what the HMAC has been calculated over, with the
HMAC field set to zeroes.
Decode the message and extract the HMAC from the data tree. This bit string
occurs in the message where the HMAC is stored, and it is a random pattern
produced by the HMAC function of the sender - it is *very* unlikely to
occur in the message more than once.
Search the message for the bitstring, if you don't find it, check your
source code and PER decoder. To be safe, copy the message to a buffer, set
the located bitstring to zero in the copy, and compute the HMAC. If it
matches, the message is OK.
If the HMAC does not match, search from the previously located bitstring
plus one. If you get a second match - copy, zero-fill, compute-HMAC and
compare as before. Repeat until you get to the end of the message or match
the HMAC.
No re-encoding of the message is required, nor is it desirable. Apart from
retrieving the HMAC from the message, the HMAC location and recomputation
is completely independent of whether the message is RAS or Annex G, much
less which version. Hence it is completely version-safe.
For non-repudiation, you must use public-private key pairs and
certificates. The message is signed by computing the HASH as above, and
then encrypting that hash with the private key.The receiver computes the
HASH as before, decrypts with the public key, and compares the result. If
they match, the message is OK, and was created by the holder of the private
key.
If a proxy is to change components, then the proxy will have to recompute
the MAC (keyed or signed) using its own credentials. In this case it is the
proxy that is attempting to guarantee the integrity and authenticity of the
message, so the EP MAC is destroyed.
If you want to just authenticate just a few fields, so a proxy/firewall can
change parts of the message, and the other endpoint can check the few, it
is best to compute the authentication code on the unencoded fields. This
can be done in a hashed CryptoToken, with the hashed values included or not
in the CryptoToken. Extreme care must be taken to ensure that the rules for
encoding the ToBeHashed are well specified.
Regards,
Douglas
At 19:08 1999-09-20 +0200, Euchner Martin wrote:
>Douglas,
>
>first of all, I'm glad to see a very interesting and fruitful discussion
here. Thus, I would rather carry on these specific topics about the syntax
and procedures on the SG16 discussion list and hear also other people's
opinions about that.
>
[snip]
[View Less]
Dear Mr.Toshiaki Suzuki
In response to your request, APC-1655 has been
allocated to your contribution.
APC-1655
> Title : Real-time system of H.262 layered video transmission
> Source : Hitachi Ltd.
Best regards,
Sakae OKUBO (Mr.)
***********************************************************
Waseda Research Center
Telecommunications Advancement Organization of Japan (TAO)
5th Floor, Nishi-Waseda Bldg.
1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
Tel: +81 3 5286 3830
…
[View More] Fax: +81 3 5287 7287
e-mail: okubo(a)giti.or.jp
***********************************************************
Documents for Q.12-14/16 Rapporteur meeting in Red Bank (18-22 October 1999)
The documents can be retrieved as
ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.???
or
http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.???
------------------------------------------------------------------------
APC- Source Title
------------------------------------------------------------------------
1645 TIPHON Proposal for an H.323 "Security Profile"
1646 Motorola Annex-H(User and Service Mobility in H.323)
1647 Lucent Mobility Agents in H.323 Reference Architecture
1648 Lucent Registration Procedure for Wireless Mobile H.323
Terminals
1649 Lucent Mobility States for the Mobile H.323 Terminals
1650 Lucent H.245 Generic Capabilities Definition and H.225
Packetization Specification for the Cellular/PCS CDMA
EVRC Voice Codec.
1651 AT&T H.323 Mobility Architecture and Protocol for Terminal,
User, and Service Mobility
1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture
and Protocol for Terminal, User, and Service Mobility
1653 PictureTel Proposed text for G.722.1 capabilities in the H.323
Implementor's Guide
1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V
Networks
1655 Hitachi Ltd. Real-time system of H.262 layered video transmission
1656
1657
----------------------------------------------------------------------------
----
[View Less]
The text below lists additions and clarifications made to
<draft-ietf-megaco-reqs-05.txt>, and now found in
<draft-ietf-megaco-reqs-06.txt>.
Until it is available in the IETF I-D directory, you can get a copy of it
at: ftp://standards.nortelnetworks.com/megaco/docs/latest
It includes clarifications asked for by ITU-T SG16 at their Berlin meeting.
If there are no more comments on this requirements draft, then I would
ask Tom Taylor to send it for WG last call.
Note that there are …
[View More]references to fill in, and a few editor's notes to
remove. I will do this in a few days if there are no other comments.
Nancy
-------------
5.4. Signal/Event Processing and Scripting
l. Provide an extension mechanism for implementation defined events
and signals with, for example, IANA registration procedures. [ADD
FOLLOWING
SENTENCE:]It may be useful to have an Organizational Identifier (i.e. ITU,
ETSI,
ANSI. . .) as part of the registration mechanism.
5.6. Test Support
b. Specifically support [DELETE103, 105, and 108 ] test line operation [ADD]
(e.g.
103, 105, 108).
5.8. Signalling Control
Establishment and provisioning of signalling backhaul channels (via
SIGTRAN for example is out of scope. [QUESTION: WHY was this marked as out
of
scope?] Answer: it has been decided that this capability is not fundamental
to the protocol, so can be kept out of scope, and handled some other way.
6.1. Resource Status Management
c. Provide a method for the MGC to request that the MG release all
resources [ADD THE FOLLOWING] under the control of a particular MGC [END OF
ADD]
currently in use, or reserved, for any or all connections.
6.2. Resource Assignment
c. Allow the use of DNS names and IP addresses to identify MGs and
MGCs. [ADD FOLLOWING SENTENCE] This shall not preclude using other
identifiers
for MGs or MGCs when other non IP transport technologies for the protocol
are
used.
8.1 MG-MGC Association Requirements
b. Allow multiple MGCs to send control messages to an MG. Thus, the
protocol must allow control messages from multiple [DELETE] IP
[ADD]signalling
addresses to a single MG.
7.3 MIB Requirements
[ADD c.]
c. H.248 MG MIB must support spirit of H.341 by either the MG, MGC, or both
acting
together.
8.2. Performance Requirements
d. Support peak calling rates (e.g. in the order of 140 calls/second) at
the
MGC on a moderately loaded [DELETE IP] IP network.
11. Requirements specific to particular bearer types
Table 1: Bearer Types and Applications
Bearer Type Applications Transit Network
================================================================
[ADD FR]
Multimedia H.323 H.323 Multimedia IP, ATM, FR
Gateway and MCU
[REPLACE SS7 with IP, ATM, FR]
Multimedia H.320 H.323 GW and MCU ISDN, IP, ATM, FR
11.1.1. Requirements for TDM PSTN (Circuit)
b. Missing - inconsistent numbering - renumber section
11.1.3.3. Media adaptation
b. Allow [ADD AAL1] AAL1/AAL2 multiple narrow-band calls to be mapped to a
single
VCC.
[ADD For AAL2] For AAL2, these calls are differentiated within each VCC
by a AAL2
channel
identifier. An AAL2 connection may span more than 1 VCC and transit
AAL2 switching devices. ATMF standards are working on an end-to-end
AAL2 connection identifier as part of the AAL2 signalling set.[REPLACE
LAST
SENTENCE WITH:] ITU Q.2630.1 defines an end-to-end identifier the Served
User
Generated Reference (SUGR). It carries information from the originating user
of the
AAL2 signalling protocol to the terminating user transparently and
unmodified.
11.2.10. Multipoint Control Units
[ADD g.]
g. The ability for the MG to function as an H.323 MP, and for the MGC to
function
as an H.323 MC, connected by this protocol (MEGACOP/H.248). It should be
possible
for audio, data, and video MG/MPs to be physically separate while being
under the
control of a single MGC/H.323 MC.
--------------
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
[View Less]
Martin,
Firstly, I hope that the mechanism for encoding the HMAC is well
understood, and the reason for using HMAC-SHA1-96 (RFC-2404).
Secondly, the decoding:
The message which arrives is a bucket of bits, inside a TPKT. (It would be
nice to have something in the TPKT to tell us whether the message contained
is encrypted, but it doesn't. :-( ) If it's encrypted, assume you can tell
and decrypt it. This is what the HMAC has been calculated over, with the
HMAC field set to zeroes.
Decode the …
[View More]message and extract the HMAC from the data tree. This bit string
occurs in the message where the HMAC is stored, and it is a random pattern
produced by the HMAC function of the sender - it is *very* unlikely to
occur in the message more than once.
Search the message for the bitstring, if you don't find it, check your
source code and PER decoder. To be safe, copy the message to a buffer, set
the located bitstring to zero in the copy, and compute the HMAC. If it
matches, the message is OK.
If the HMAC does not match, search from the previously located bitstring
plus one. If you get a second match - copy, zero-fill, compute-HMAC and
compare as before. Repeat until you get to the end of the message or match
the HMAC.
No re-encoding of the message is required, nor is it desirable. Apart from
retrieving the HMAC from the message, the HMAC location and recomputation
is completely independent of whether the message is RAS or Annex G, much
less which version. Hence it is completely version-safe.
For non-repudiation, you must use public-private key pairs and
certificates. The message is signed by computing the HASH as above, and
then encrypting that hash with the private key.The receiver computes the
HASH as before, decrypts with the public key, and compares the result. If
they match, the message is OK, and was created by the holder of the private
key.
If a proxy is to change components, then the proxy will have to recompute
the MAC (keyed or signed) using its own credentials. In this case it is the
proxy that is attempting to guarantee the integrity and authenticity of the
message, so the EP MAC is destroyed.
If you want to just authenticate just a few fields, so a proxy/firewall can
change parts of the message, and the other endpoint can check the few, it
is best to compute the authentication code on the unencoded fields. This
can be done in a hashed CryptoToken, with the hashed values included or not
in the CryptoToken. Extreme care must be taken to ensure that the rules for
encoding the ToBeHashed are well specified.
Regards,
Douglas
At 19:08 1999-09-20 +0200, Euchner Martin wrote:
>Douglas,
>
>first of all, I'm glad to see a very interesting and fruitful discussion
here. Thus, I would rather carry on these specific topics about the syntax
and procedures on the SG16 discussion list and hear also other people's
opinions about that.
>
[snip]
[View Less]
Contribution APC-1654 ISO/IEC addressing in H.323 Appendix V has been
uploaded to the incoming directory.
-----
François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com
<mailto:audet@NortelNetworks.com>
Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com
<http://www.nortelnetworks.com/>
Douglas,
first of all, I'm glad to see a very interesting and fruitful discussion here. Thus, I would rather carry on these specific topics about the syntax and procedures on the SG16 discussion list and hear also other people's opinions about that.
All my comments are in the text below.
Regards,
Martin
-----------------------------------------------------------------------
| Dipl.-Inf. Phone: +49 89 636-46201
| Martin Euchner Fax : +49 89 636-48000
| …
[View More]Siemens AG
| ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de
| Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html
| Otto-Hahn-Ring 6 Internet: http://www.siemens.de
| D-81730 Muenchen
| __________________
| Germany
-----------------------------------------------------------------------
-----Original Message-----
From: Douglas Clowes [SMTP:dclowes@ozemail.com.au]
Sent: Monday, September 20, 1999 3:00 AM
To: Euchner Martin
Cc: El-Gebaly, Hani; inowag(a)imtc.org
Subject: RE: Security
At 14:10 1999-09-17 +0200, Euchner Martin wrote:
>Douglas and Hani,
>
>
>first I would like to confirm, that Annex J applies the method as
described by Hani in a previous mail.
>
>Let's assign some mnemonics to the procedures on the table for easier
discussion and let's call this method the "emptying method" as the ICV/hash
field is emptied before the calculation.
>
>Douglas proposed two alternative methods for computing ICVs or hash values:
>The first method - let's call it the "substitution method" for short -
works in a similar way as the emptying method except that there is only one
ASN.1 pass and the hash/icv value has to be located in the coded ASN.1 by a
particular (unambiguous) bit pattern.
>
>I would name the other proposed method as the "envelope method" as new
ASN.1 syntax is put around the protected message.
>
>While it is true that the emptying method suffers from the versioning
problem, I do not quite understand why this does not apply also to the
substitution method. How does a receiver with a lower protocol version know
which fields to exclude the recomputation of? Also I doubt that the trail
and error method for locating the bitpattern is efficient.
Firstly, I am assuming that the Message Authentication Code ((H)MAC) is
being performed over the entire message. I'm not sure if this assumption is
common to us all, hence I am explicitly stating it here. This implies that
there are *no* fields to be excluded from any recomputation.
This is correct. In "authenticaton & integrity" mode of Annex J, the (H)MAC is computed over the entire message after the message has been ASN.1 encoded into a bitstring. This step is done by the sender as well as the receiver.
For your substitution method, I think you are right and the method described should work without any versioning problems.
I guess that the crucial procedure at the receiver is roughly as follows:
1) receive the message
2) locate and find the sender's hash value; call this result RV.
Actually, how does the receiver know where to find the hash bits in the message bitstring? The position of the hash value may vary from one RAS message to another. This sounds like a problem.... Any ideas please?
The only way I could think of is to ASN.1 decode the message, and then re-encode it with a known (default) pattern and find that pattern in the received message. The position of the hash value in the received message should correspond to the found position of the known pattern. Is it guaranteed that this procedure works independently of protocol versions???
3) reset the hash value bits in the received message to some default pattern, then recompute the keyed hash over the message; call the result HV
4) compare HV == RV etc ....
Since the
computation is over a bit string of unknown/indeterminate construction,
versioning cannot affect the result, because at the time you generate or
check the hash, you don't even care that it's an encoded message, much less
PER encoded, or even ASN.1, or even RAS/Annex G - it's just a bit string.
If I'm not clear on that, let me know and I'll try again to explain it.
Secondly, as long as the "bitpattern" is sufficiently random, it is very
unlikely to occur in the message randomly - one in 2^96, 2^128, or 2^160
depending on algorithm. Of course, if one uses zeroes or spaces or the
gatekeeperId, it's more likely, but if one uses the HMAC from the previous
message as the bitpattern, you might get a collision every few years/millenia.
>
>I'm not quite certain whether I fully understood the envelope method. Is
it true that the BESTP could be a RRQ for example, while the ABESTP would
be the actual message sent through the wire? How does this method address
the versioning issue? What happens when BESTP sees some extensions?
Again, the versioning is not an issue, because the thing that is being
signed/encrypted is just a bitstring. The checking/decrypting independent
of the contents. It's an encapsulation or tunnelling mechanism, independent
of what is being encapsulated or tunnelled.
>If this is the case then it is probably already far too late for changing
to the envelope method if it works at all. It appears to me that H.225.0
would have to be changed fundamentally.
Well, not really too late, and it could be made to work, but that is more
properly a subject for the SG16 list, rather than the iNOW! list. Since the
GRQ/GCF can indicate that the enveloped method is supported, and should be
employed, it's just a simple versioning issue.
This will test my understanding of ASN.1 and PER encoding... (someone
correct me if I'm wrong).
In H.225.0, RasMessage is a PDU and is identified in the encoded message by
a tag value. I believe that H323-UserInformation is another. These are
differentiated in an inbound PDU by their tag value (and channel).
Let's invent a new H.225.0 PDU call SecurityMessage, defined as:
SecurityMessage ::= SEQUENCE
{
encryptionAlgorithm OBJECT IDENTIFIER OPTIONAL,
encryptionParams ParamS OPTIONAL,
signatureAlgorithm OBJECT IDENTIFIER OPTIONAL,
signatureParams ParamS OPTIONAL,
messageText OCTET STRING,
signatureText OCTET STRING OPTIONAL
}
toBeSecured TYPE-IDENTIFIER.&Type(RasMessage)
The message could be signed, or encrypted, or signed and encrypted, or
neither (in which case it should be just a plain RAS message).
* Signed only: encode the RAS PDU into the toBeSecured octet string, and
place in the messageText OCTET string. Compute the signature into
signatureText. Set signatureAlgorithm and signatureParams with appropriate
values.
* Encrypted only: encode the RAS PDU into the toBeSecured OCTET string and
encrypt, placing the ciphertext result into messageText. Set
encryptionAlgorithm and encryptionParams with appropriate values.
* Signed and Encrypted: encode the RAS PDU into the toBeSecure OCTET
STRING. Compute the signature into signatureText. Encrypt toBeSecured into
messageText. Set the algorithm OIDs and params with appropriate values.
Possible variations include:
o Encrypt the signatureText with the same algorithm and params used on
messageText.
o Next the signature structure within the encrypted structure -
SecurityMessage ::= SEQUENCE
{
encryptionAlgorithm OBJECT IDENTIFIER OPTIONAL,
encryptionParams ParamS OPTIONAL,
encryptedText OCTET STRING,
}
SignedRasMessage
{
signatureAlgorithm OBJECT IDENTIFIER OPTIONAL,
signatureParams ParamS OPTIONAL,
signatureText OCTET STRING OPTIONAL,
signedText OCTET STRING
}
ToBeEncrypted TYPE-IDENTIFIER.&Type(SignedRasMessage)
ToBeSigned TYPE-IDENTIFIER.&Type(RasMessage)
The process: encode the RAS message, as ToBeSigned, into signedText. If
signing, set signatureAlgorithm and signatureParams and calculate
signatureText. Encode SignedMessage into encryptedText. If encrypting, set
encryptionAlgorithm and encryptionParams, and encrypt encryptedText.
In either case, and in H.235 as it stands, ParamS would be redefined as:
ParamS ::= SEQUENCE
{
ranInt INTEGER OPTIONAL,
iv8 IV8 OPTIONAL,
...,
keySequenceId INTEGER(0..??) OPTIONAL
}
to accommodate a change in keys for delayed and out of order message delivery.
>Finally, the ICV field is no longer always at the end of the message as
certain H.225.0 v3 RAS messages have been extended by new fields since
version 2.
Well, I had the H.225.0 AnnexG messages in mind when I said that, and even
then, it's not literally true. But it doesn't matter logically, as long as
you can find the correct part.
>Comments please.
>
>
>Regards
>
>Martin.
>
Regards,
Douglas
[View Less]
Douglas,
please see my answers below in the text.
Regards,
Martin.
-----------------------------------------------------------------------
| 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
| Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html
| Otto-Hahn-Ring 6 Internet: …
[View More]http://www.siemens.de
| D-81730 Muenchen
| __________________
| Germany
-----------------------------------------------------------------------
-----Original Message-----
From: Douglas Clowes [SMTP:dclowes@OZEMAIL.COM.AU]
Sent: Monday, September 20, 1999 1:38 AM
To: ITU-SG16(a)mailbag.cps.intel.com
Subject: Re: Questions on H.235
At 12:01 1999-09-17 +0200, Euchner Martin wrote:
>Douglas,
>
>as I pointed out in a former email, I'm adding the source identifier to
the ClearToken in H.235v2. As you said this will improve the security.
>
>
>On the other hand however, there is a specific problem using the
destination identifier on multicast RAS messages like GRQ for example: Most
of the recipients would then think that the received message is not
destined for them. This was therefore the reason to use the source
identifier instead of the destination identifier on GRQ (in violation of
ISO protocols).
>
>For unicast RAS messages, I could add the destination identifier of
course. But I do not know how to handle the multicast RAS message in a
better way. Using This would result at least in a partial improvement.
OK, I forgot the multicast case. However, the generalId should, IMHO, be
either that of the recipient (unicast) or not present (multicast), rather
than that of the sender as shown.
H.235v2 fixes this.
>Yes, H.235v2 is on its way and I am already preparing a new, improved
version. You will see this version at the upcoming Rapporteurs meeting in
October soon. So far, no modified version of H.235 has been presented.
While you're at it, 10.3.2 method for forming a key from a password is
embarrassingly weak. A short password ('X' for example) produces a key
which is mostly zero bits. Even a longer pass phrase will prod use a key
with high order bits set to zero in each byte, and similar characteristics
reducing a keys strength significantly.
Most credible schemes would use a hash function (MD5 or SHA1) over the pass
phrase, and would not fill out the pass phrase with zeroes.
The amount of entropy in such a key will be very low, and one should not
use such a key for bulk encryption. To do so would provide an attacker with
a large amount of cryptotext, some of which will be known, enabling a
known-cryptotext attacks. An additional key generation/exchange mechanism
should be employed.
It is true that 10.3.2 does not provide absolute security . A more secure way would be to use hashed passwords instead of the plain PW as you wrote. However, the entropy does not increase effectively by hashing. Thus, implementations should check and avoid weak passwords by some means. Anyway, the (hashed) password is not applied to bulk encryption; rather it is used for registration and authentication purposes.
>Denial of service attacks: It seems that this is an issue as you
described. A good countermeasure is to include a sequence number into the
signed message. The receiver should check the sequence number and should
verify the signature before proceeding any further. This should be fixed as
well in H.235v2.
In UDP based protocols, strict sequencing is not possible, because message
order and delivery and duplication are not guaranteed. An eavesdropper can
easily generate a sequence number in the range, so a legitimate message
will duplicate an illegitimate message sequence number.
A signature is a more secure check.
a) correct: strict sequencing on UDP does not work. RAS/Annex J uses the randomVal as a counter, making several messages with the same timestamp unique. This allows to detect duplicated messages.
b) When message integrity is applied to the entire message, an attacker no longer is able to generate fake messages just by guessing the counter, as the attacker cannot compute the correct hash without possessing the password.
>Generally, I agree with you that the procedure described in B.4.2 using
the XOR does not really provide any reasonable security. This method just
provides a certain (instance) authentication of just one message field (the
GK-identifier); any other field in the RAS message is not authenticated or
protected by any means; thus replay or modification attacks on these parts
are possible without detection. To be honest with you, I don't like
procedure B.4.2 either for these reasons. Anyway, B.4.2 due to its weak
security is therefore not part of H.323 Annex J.
Good. It should not be part of H.235 either.
Even if we all agree to remove B.4.2, does the ITU procedure (maintaining backwards compatibility) allow us to do?
>A much more secure protocol is thus being applied in H.323 Annex J:
Protection of the entire RAS message using either HMAC-SHA1 (with a
symmetric key/password) and rapid integrity checking, or an
RSA-SHA1/RSA-MD5 digital signature.
I understand that HMAC-xxx-96 gives away less information on the key, and
should be preferred for a long term password based mechanism.
Sounds as a good suggestion. Annex J will reflect this change.
>Let me just mention that when a message gets lost, B.4.2 says that the
most recent random should be used.
Trouble is that, for a time, neither party knows that a message is lost. If
I send you an xRQ and you send me a new random in the xCF, which random do
you use to check my next message? It needs to be different depending on
whether the xCF was lost or not. If you use the new one, and my next
transmission is a retransmit of the original xRQ, will you reject it
because it doesn't use the new random? You will have to check both.
If I send you an xRQ that lives for a while in a router queue, receive a
new random and use it in a message that arrives at you before the earlier
one (out of order reception happens) and you check it against the new
random, it matches. When the first message arrives, it has the old random.
Will you reject it or ignore it? Either way, will I understand that I have
to recompute it and send it again. If you reject it, I may fail the
operation. If you ignore it, I may resend the same bit-pattern with the old
random.
This issue is closely linked with B.4.2; luckily, Annex J does not reference it.
>Diffie-Hellman on Call Signaling channel: H.323 Annex J addresses two
scenarios: In a small closed environment with shared secrets among all the
participants. Then "signing" Diffie-Hellman tokens can be done by the
shared secret and using an HMAC-SHA1 (see the baseline profile). The much
more scaleable scenario is satisfied with digital certificates and
cryptographic signature upon the Diffie-Hellman tokens (see the
sophisticated profile).
Again, HMAC-SHA1-96 seems the preferred mechanism in IPsec (RFC-2403 and
2402).
see some lines above: Annex J will use the truncated hashing
I agree with you there, but wonder if it's better to sign the entire
message, just the DH component, or both.
Actually, Annex J offers both methods: signing the entire message or signing only a subset including the DH params.
Regards,
Douglas
>Regards,
>
>Martin.
[View Less]
Paris, France, 15-17 December 1999
Media Gateway Control 99 Conference.
MGCP, Megaco, H.248. How to assure convergence between IP and PSTN networks.
Technical challenges, trials, interoperability tests, normalization work.
Call for papers: www.upperside.fr/bamgc.htm
Thanks
Dear Colleagues,
This is just a reminder that the hotel where we are holding the upcoming
Q.11-15 meeting will hold a block of rooms until this Wednesday, 22
September. Also, please remember to register for the meeting as
described in the meeting announcement so that we can plan for the size
of the meeting.
Regards,
Glen
--
Glen Freundlich ggf(a)lucent.com
Lucent Technologies office: +1 303 538 2899
11900 N. Pecos …
[View More]fax: +1 303 538 3907
Westminster, Colorado 80234 USA
[View Less]
Aparna,
please note, that Jim Toga is no longer editor of H.235. I took over responsibility to carry on H.235 version 2. Anybody with questions, suggestions and improvements should get in touch with me therefore.
1. Relation of registration info by GK: The GK can associate the registration information through the delivered endpointID and callID. Further on, commercially available stacks offer identifications means by messages handles or simply IP addresses for example. All this could be …
[View More]useful in keeping track of state and context.
2. Key update: H.235 offers a key update (key refreshment) procedure for the media session key; this procedure is not applicable to RAS for the following reasons:
a) Passwords are subscription-based information. The subscription procedure (registration, obtaining, refreshing PWs) are not part of the recommendation. This all can be achieved by some means out-of-band. By such a procedure you can also refresh your passwords of course.
b) Diffie-Hellman keys act as a master key. There is no explicit key update procedure for such keys. Implicitly, you could terminate (close) the connection and immediately re-open/reregister; thereby establishing automatically a new key.
Regards,
Martin
-----------------------------------------------------------------------
| 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
| Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html
| Otto-Hahn-Ring 6 Internet: http://www.siemens.de
| D-81730 Muenchen
| __________________
| Germany
-----------------------------------------------------------------------
-----Original Message-----
From: Aparna Saha [SMTP:apsaha@HSS.HNS.COM]
Sent: Monday, September 20, 1999 6:45 AM
To: ITU-SG16(a)mailbag.cps.intel.com
Subject: Queries on RAS security !!
Hi Jim,
I have a few queries related to H.235, specifically, RAS security.
This is regarding the RAS procedures for authentication . During the GRQ-GCF
exchange, the security info ( the secret key and the algorithmId ) gets
established with the GK. For the subsequent RRQ, how does the GK relate the
RRQ with the info stored ?
Is there any mechanism for refreshing keys in RAS ?
Thanks and regards,
Aparna.
[View Less]
