Re: ISAKMP and SSL

["Salah Aly" <saly@students.depaul.edu>]

> 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...


> 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                                   ekr@rtfm.com]
> >            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
>
>
>