[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Just Fast Keying (JFK) draft
I am somewhat disappointed that there appears to have been almost no
substantive discussion of JFK on the list. This may indicate that the
protocol is secure, or it may indicate that nobody has been bothered to read
it - which given the effort put into previous flames over the subject of
keying would be somewhat disappointing.
In the hope of engendering some debate on the matter I have been examining
the algorithm, in particular comparing it to my XML Key Agreement Service
Specification available in pdf form from
http://www.xmltrustcenter.org/research/xkass/index.htm, the IETF draft
format will be available sometime today or tommorow, I would recomend people
read the pdf which has the benefit of subscripts and diagrams.
The main differences between JFK and XKASS are:
JFK requires 2 round trips
JFK provides a certain level of DoS protection
JFK allows the initiator to avoid disclosure of its identity to 3rd parties
JFK requires
the initiator to perform 2 signature verifications, 1 creation, 1 DH
exponent
the responder to perform 1 signature verification, 1 online
creation,
1 signature that can be performed offline, one DH exponent.
JFK does not assume that the initiator has knowledge of the public key of
the responder at the start of the protocol.
XKASS also supports an encryption mode which does not support PFS
XKASS requires 1 round trip
XKASS requires
the initiator to perform 1 signature creation, 1 verification, 1 DH
exponent
the responder to perform 1 signature creation, 1 verification, 1 DH
exponent
XKASS assumes that the initiator has access to the public key of the
responder at the start of the protocol.
The main difference is in the design of the first round trip which has the
purpose of defending against a limited set of DoS scenarios and to partially
conceal the identity of the requestor.
The question then is whether the scenarios in question are realistic and
whether the defenses are effective in practice.
On the question of concealling the identity of the initiator I am skeptical.
As with the case of Chaum's digital cash it is likely that the identity of
the participants can be deduced from the IP addresses alone so the
cryptographic concealment of my identity at the message level does not
excite me greatly. Even my AT&T roadrunner IP address that is issued on a 15
minute (!) lease has never changed in 6 months of service but wait for
Friday when they turn off @home)
The threat model for denail of service implicit in the paper is as follows:
1) The DoS attacker sends an IP packet with a correct source address.
2) The DoS attacker sends an IP packet with a fictitious source address.
In case (1) the DoS attacker has the ability to respond to messages sent by
the target but the target has the ability to respond to the attack by
selectively blacklisting keying requests from the source.
In Case (2) the DoS attacker cannot complete the second phase of the JFK
exchange and thus cannot cause the responder to perform expensive CPU
operations.
This suggests that the DoS protection does serve a usefull purpose in the
context of the IPSEC exchange. The question is whether the defense justifies
the second round trip.
If it was agreed that the issue of identity concealment was bogus it would
be possible to create a combined JFK/XKASS type exchange that would execute
in one round trip or two at the option of the responder. The responder would
only require the second round trip in the case that it had actually detected
a DoS attack.
This particular implementation might have the problem of introducing more
complexity to the protocol than is desirable in IPSEC for the sake of saving
one round trip in a crypto-intensive protocol - although the complexity
would not be very great.
In the context of SOAP exchanges however the ability to save a round trip is
likely to be considerably more important, particularly since it is more
likely that the key exchange servers will be dedicated machines that do
nothing but key exchange and have the cryptographic hardware to support it.
If I have time before the IETF meeting I will try to apply the security
methodology introduced in the XKASS paper to the JFK scheme.
In particular I would like to be sure that the shared secret is in fact
securely bound to all the context information of the exchange that might be
of importance. In XKASS I took a possibly excessive approach, the
established shared key has dependencies on practically every security
parameter in the protocol. I remain keen on the idea of binding to the
credentials of the parties however, this provides a pretty robust defense
against credential substitution attacks in which a party has more than one
certificate for the same key.
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
> -----Original Message-----
> From: Steven M. Bellovin [mailto:smb@research.att.com]
> Sent: Tuesday, November 20, 2001 9:26 AM
> To: alexey.vyskubov@nokia.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Just Fast Keying (JFK) draft
>
>
> In message
> <20011120124450.GA18085@terrapin.research.nokia.com>, Alexey Vyskubo
> v writes:
> >Hello,
> >
> >On Wed, Nov 14, 2001 at 11:52:10PM +0200, Angelos D. Keromytis wrote:
> >> Without further ado, here's the link to the just-submitted I-D:
> >>
> >>
> http://www.cs.columbia.edu/~angelos/Papers/draft-keromytis-jfk-00.txt
> >
> >Is it available still?
>
> I'll let Angelos figure out what happened to his copy; however, the
> official version of the draft is now available from the IETF,
> but using
> a different name -- it's an official IPsec WG draft. Anyway, you can
> retrieve it at
>
> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-jfk-00.txt
>
>
> --Steve Bellovin, http://www.research.att.com/~smb
> Full text of "Firewalls" book now at
http://www.wilyhacker.com
Phillip
Follow-Ups: