Subject: Re: ISAKMP and SSL

From: Ibrahim <[email-masked]>
Date: Thu, 01 May 2003 12:17:17 +0200

Hi all,
Most key management protocols (ISAKMP, TLS Handshake, Oakley, SKEME, SKIP…)
even in SSH are based on Diffie-Hellman.
This can be an additional reason to this issue if we saw that we develop the
same key management protocols but every time with a little bit change.
what i want to say is why every security protocol should propose his own key
management schemes if we can unify all this work? I think the first ISAKMP
proposition was in this road.

 In addition,

1 – about identity protection new service. I am not convinced with (a) +
(b) solution for SSL. Identity protection can also be the mask of a
number of people using the same IP address. Id. Prot. can be
used when one host has multiple identities and wishes to mask who is
behind a specific handshake. (even with different X509 Cert.).

2 - Modularity of SSL Protocol.
SSL is a module security protocol. Any ISAKMP integration requires
changing only the Handshake part.

3 – TLS extension proposes to extend the work of TLS protocol in new
environment (..) and to add some new mechanism in authentication
(Sending URL certificate, authentication with attribute …) All these
mechanisms are even implemented in ISAKMP or can be quickly done. For
ISAKMP the new environment can be multi-cast diffusion, MAP protocol for
UMTS...

4 - Interoperability between different security protocols.
Several security protocols could share the same key management code.
This simplifies migration from one protocol to another and reduces the
amount of duplicated functionality within each security protocol.

Ibrahim

Eric Rescorla wrote:

> > When I read RFC 2408 they described ISAKMP as a generic key management
> > protocol for all security protocols but till now the large deployment of
> > ISAKMP was only with IPSEC
> > My question is, can we use it with SSL/TLS?
> > The goal of this issue is to add new services in SSL/TLS (identity
> > protection, attribute certificate passing for access control schemes,
> > non-repudiation…).
>
> The basic answer here is no.
>
> TLS has its own key management scheme and really isn't designed
> to have pluggable key management. That said, with respect to your
> specific desired security services:
>
> (1) You can get identity protection for TLS in a number of ways,
>     none quite as good as you would get with IPsec.
>
>     (a) do an initial anonymous DH exchange and then do the
>         ordinary handshake. This still allows an active attacker
>         to get both identities.
>
>     (b) do an initial cert-based exchange (this exposes the
>         server's identity) and then rehandshake to have the
>         client identify.
>
>     (c) combine the above two techniques :)
>
> (2) TLS has an extensions mechanism so you could use that to
>     pass around attribute certificates.
>
> (3) ISAKMP doesn't really offer non-repudiation either, so you
>     wouldn't get any benefit from melding it with TLS.
>
> -Ekr
>
> --
> [Eric Rescorla                                   [email-masked]]
>            Web Log: http://www.rtfm.com/movabletype

--
____________________________________________________
Ibrahim HAJJEH
Ecole Nationale Supérieure des Télécommunications
Departement Informatique et Réseaux
Tél.:+33 01 45 81 71 06     Fax.: +33 01 45 81 31 19
46 rue Barrault, 75634 PARIS cedex 13

---

From: "Salah Aly" <[email-masked]>
Date: Thu, 1 May 2003 08:04:10 -0500

> Hi all,
> Most key management protocols (ISAKMP, TLS Handshake, Oakley, SKEME,
SKIP.)
> even in SSH are based on Diffie-Hellman.
I do not think your statement is correct, not all of the key management
protocols depend on Deffie-Hellman..
for example, Shamir's Secret Sharing is a way to manage and distribute the
key, it depends on polynomial interpolations...

> 1 - about identity protection new service. I am not convinced with (a) +
> 3 - TLS extension proposes to extend the work of TLS protocol in new
> (Sending URL certificate, authentication with attribute .) All these
> > > non-repudiation.).

---

From: Eric Rescorla <[email-masked]>
Date: 01 May 2003 06:27:52 -0700

> proposition was in this road.
That's reasonable sounding. I'm just telling you that it's not 
practical to retrofit it to TLS.

> behind a specific handshake. (even with different X509 Cert.).
I don't understand what point you're trying to make here.

> changing only the Handshake part.
In theory perhaps. In practice the TLS key management and record protocol
are relatively tightly coupled. Moreover, like 75% of the TLS code
is key management so it's not clear why you'd want to gut it,
shove in ISAKMP, but retain the record layer.

> ISAKMP the new environment can be multi-cast diffusion, MAP protocol for
I don't understand what point you're trying to make here. I
don't deny that you can obtain the requested security services
using some mechanism other than TLS, but the probability of
TLS incorporating ISAKMP key management is approximately zero.
Therefore, if you want to use TLS and you want these services,
you need to start thinking about a different approach.

> amount of duplicated functionality within each security protocol.
Yes, that's fine, but we live in a world where TLS code
is already very widely deployed, so creating a new TLS/ISAKMP hybrid
is going to introduce complication, not reduce it.

-Ekr

---

From: Mark Baugher <[email-masked]>
Date: Thu, 01 May 2003 08:56:35 -0700

hi Ibrahim,
   In addition to some of the advantages that you cite, another claimed 
benefit of the ISAKMP approach is increased security by having a single key 
establishment entity on the computer rather than several.  Although some of 
us "drank that kool aid," I think that this is not the current direction of 
IPsec (there are some good arguments against it, notably complexity) and 
the matter is probably of little interest to most people on this list.  At 
least that's my impression of the way things stand.

Best regards, Mark
At 12:17 PM 5/1/2003 +0200, Ibrahim wrote:
>1  about identity protection new service. I am not convinced with (a) +
>3  TLS extension proposes to extend the work of TLS protocol in new

---

From: Ibrahim <[email-masked]>
Date: Thu, 01 May 2003 19:28:57 +0200

Mark, I totally agree with you
The idea of extending the work of ISAKMP to other security protocols began in 1996
by Cisco corp. J.  Smith has also talk about it in the
ietf-tls mailing list.
But i think that the work and effort involved in this WG during all last period in
defining a robust key exchange mechanism should be used and
gained in other WG.
Centralizing ISAKMP usage to IPsec (IKEv2) remove all the advantage of  this
“generic” key exchange protocol. We should not forget that ISAKMP
was designed as an application layer protocol so normally it benefit of all the
advantage of this layer and can especially establish a secure connection
for all network security protocols so why we don’t try to implement it outside
IPsec?

> I don't understand what point you're trying to make here.

You should read the proposed TLS extension draft about authenticating
TLS server that host multiple virtual servers.

> you need to start thinking about a different approach.

Sure, SSL will not offer these services but ISAKMP can.

> is going to introduce complication, not reduce it.

 I know that SSL is the most deployed security protocol but this is only
due to his native integration in web server, client browsers and because
80% of the SSL usage is with HTTP. Adapting SSL for new services, the
deployment of IPv6 arch., IKEv2 design can also introduce complication.

Ibrahim

---

From: Eric Rescorla <[email-masked]>
Date: 01 May 2003 10:41:03 -0700

> TLS server that host multiple virtual servers.
Ibrahim, I'm the editor of the main TLS document. I've read the
extensions draft times. I still don't understand what point
you're trying to make here about identity protection.

> Sure, SSL will not offer these services but ISAKMP can.
Right, but since noone is going to use ISAKMP with SSL, 
if you want these features in the context of SSL you have to think
about how to add them to SSL.

> deployment of IPv6 arch., IKEv2 design can also introduce complication.
TLS has been quite robust when applied to new application
layer protocols, actually. Very little has had to be done
(the virtual servers stuff being the notable exception)

IPv6 architecture and IKEv2 design have nothing to do with
TLS because TLS sits at a different layer of the stack.

-Ekr

                http://www.rtfm.com/

---

From: [email-masked]
Date: Thu, 1 May 2003 22:12:51 -0400

> Most key management protocols (ISAKMP, TLS Handshake, Oakley, SKEME,
SKIP…)
> proposition was in this road.

It seems like whenever someone needs a key management protocol, they look
at the ones that already exist (maybe), decide that they are all too
complicated and don't match their needs very well, so they invent a new
one. Then they add features to make it possible for future designers to use
theirs instead of inventing a new one again. In the process, they end up
with a design that is too complicated and doesn't match anyone's needs very
well.

Some people would say that where we've failed is in coming up with a key
management protocol that works for everyone. I disagree. I think that our
failure has been in believing that a single key management protocol can
work for everyone and continue trying to invent it.

The cryptographic guts of these protocols has evolved over time, but not
that much. The real differences come from the different requirements of
different protocols. SSL/TLS runs over TCP, making all kinds of framing and
retransmission issues much simpler. It was developed for browsers and web
servers, where authentication is inherently asymmetric. The browser wants
to authenticate the DNS name of the server, which is fairly tightly tied to
the IP address. But the server doesn't care about the browser's address...
it wants to authenticate the name of the user at the browser; a user who is
likely to move around. Usually today, the server doesn't authenticate the
browser at all. That authentication takes place at a higher layer
(typically with a password in the http header or even a higher layer).

IPsec serves a different audience. Actually several different audiences,
and we're still dealing with their different requirements.

So I believe the "lets design this thing once and for all and have everyone
use it" is a distraction from getting real work done. Yes, look at what's
out there. But don't lose track of the problem you're trying to solve, and
don't spend too much time trying to solve the problems you think someone
else may have someday. They won't thank you for it.

      --Charlie

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 May 2003 09:37:34 -0400

At 3:49 PM -0700 4/30/03, Mark Baugher wrote:
>At 05:40 PM 4/30/2003 -0400, Stephen Kent wrote:
>>At 7:50 PM +0200 4/30/03, Ibrahim wrote:
>>>Hi all,
>>>Thank you in advance
>>SSL/TLS has its own, tightly couple key management protocol, so it 
>>would not be appropriate to try to use ISAKMP.
>
>I think the confusion comes from the fact that the ISAKMP RFC says 
>it could be applied to TLS.
>
>Mark

It lied :-)

Steve