[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
[192.94.214.100])
by portal.ex.tis.com (8.9.1/8.9.1) with ESMTP id OAA24429
for <ipsec@ex.tis.com>; Thu, 12 Nov 1998 14:39:01 -0500 (EST)
(EST)
(EST)
(4.1)
id xma021401; Thu, 12 Nov 98 15:04:14 -0500
5.0.1460.8)
id WS9ZKV3Z; Thu, 12 Nov 1998 14:37:00 -0500
5.0.1460.8)
id WP0Y58GN; Thu, 12 Nov 1998 14:36:39 -0500
Message-ID: <364B38C5.890B4271@americasm01.nt.com>
Date: Thu, 12 Nov 1998 14:36:38 -0500
From: "Amal Maalouf" <Amal.Maalouf.amalmaal@nt.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: ipsec@tis.com
Subject: IKE questions.
Content-Type: multipart/alternative;
boundary="------------D0EE2DDA8EB57A6F4C2E0A0A"
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk
--------------D0EE2DDA8EB57A6F4C2E0A0A
Content-type: text/plain; charset="us-ascii"
I have few questions/clarifications on the IKE draft
(draft-ietf-ipsec-isakmp-oakley-08.txt):
1. It is not clear from the document how authentication using public
keys
or the variant to public keys provide authentication (in the sense
that
both peers are sure that they are talking to themselves and not to a
man-in-the-middle)
When using public keys authentication it is not clear what HASH_I
and HASH_R
use as keys.
Section 5 states:
For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I |CKY-R)
For authentication with digital signatures, HASH_I and HASH_R are
signed and verified; for authentication with either public key
encryption or pre-shared keys, HASH_I and HASH_R directly
authenticate the exchange.
"hash" in the above formula is not defined anywhere else so I am
assuming its the hash
algorithm that the two peers negotiated in the SA payload so far,
but the clause "HASH_I
and HASH_R directly authenticate the exchange" gives the impression
that some kind
of secret only known to the two peers that ensures to one peer that
the other is indeed
who he claims he is, is being used as a key. (I am assuming that
the "hash" function is
using a symmetric key - please correct me if that's not the case).
Since the only shared key between the two peers at this stage is the
Diffie-Hellman one
then how is authentication achieved?
Even Section 5.2 states:
Using encryption for authentication provides for a plausably deniable
exchange. There is no proof (as with a digital signature) that the
conversation ever took place since each party can completely
reconstruct both sides of the exchange.
By the way, don't see how the "variant of public key" method is
correcting this either.
I am sure I am missing something, so please let me know what I've
overlooked.
2. Cert-I_b is not defined anywhere in the document but is used in the
variant public key
Phase 1 exchanges. What is its use in this exchange and why is it
optional?
3. Client negotiation seems pretty vague or incomplete. By reading the
archives of this list,
the ID payload in Phase 2 has been a subject of many discussions.
>From the archives
there is mention of dynamically adding SPD entries based on these
ID payload
contents, but nowhere in the drafts (IKE or the others) was I able
to find mention
of that. Could you please point me to where this is defined?
The only way Client negotiation made sense to me is to not to have
to have an IKE
engine on all hosts/gateways, but have some other IKE server/gateway
do that negotiation
on the client's behalf. If that's the case, then how does the
client pass his intent
to the IKE server/gateway that it wants negotiation to be done on
its behalf? and how
does the IKE server/gateway communicate the negotiated SA (protocol
SA in this case)
back to the client, so that the client may use it in its secure
communication?
Are these configurable? Please point me to where these are defined
or indicated to
be outside the scope of the IPsec protocol suite.
Thanks.
--
Amal Maalouf
Nortel Networks
Tel: (613) 765-5649 Fax: (613) 765-2186
e-mail: amalmaal@nortel.ca
Follow-Ups: