[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SOI: identity protection and DOS
The out-of-band channel is used before bootstrap.
I infer that both self-singed cert and pre-shared key using this channel
with
the same requirement.
I am comparing the usings between public key in the self-cert and pre-shared
key.
You seems agree that the self-signed cert need encryption (well, except
public key) for
the sake of 'id protection'.
Hence, you will agree that both using of these require
authentication and encryption for the distribution (out-of-band) channel.
Also, if you agree to encrypt cert for 'id protection' while transmission
then
the storage of cert will require encryption.
Using self-signed CA cert is subject to MIM attack,
it will have "chain reaction" (...) if the attack is successful.
(assuming no out-of-band secured channel is used and
the CA's public key expired from time to time,...)
--- David
PS. Regular cert or self-signed cert
requires integrity check on the cert itself for tampering proof.
----- Original Message -----
From: "Paul Koning" <ni1d@arrl.net>
To: <ietf_davidchen@hotmail.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Wednesday, November 28, 2001 3:06 PM
Subject: Re: SOI: identity protection and DOS
> >>>>> "david" == david chen <ietf_davidchen@hotmail.com> writes:
>
> david> Agree, However, the self-cert does not use PKInfrastructure to
> david> authenticate the public key in the cert; What is used to
> david> authenticate the public key is the same requirement as that of
> david> pre-shared key. The only difference is the self-cert (or any
> david> cert) does *not* (it is still argued in this thread for id
> david> protection) requiring an encrypted distribution channel.
>
> david> In the point of 'id protection', the self-cert (or any cert)
> david> requires some encryption but not public key in the cert. If
> david> 'id protection' is true, we see the self-serve still require
> david> some form of encrypted secure channel between peers.
>
> There are three cases to consider; for each, you can ask whether for
> that case there is a requirement for integrity, and a requirement for
> confidentiality.
>
> 1. Initial distribution of keying material (bootstrapping).
> 2. Storage of the keying material.
> 3. Use of the keying material for IKE or similar session-key
> establishment protocol. (Here, "confidentiality" can mean a
> mechanism that proves possession of a secret without disclosing it,
> not necessarily sending the secret itself in encrypted form.)
>
> For preshared secret, the answers are:
> 1. needs confidentiality and integrity
> 2. ditto
> 3. ditto
>
> For self-signed certs, the answers are:
> 1. need integrity
> 2. ditto
> 3. ditto. If you want "id protection", you also want confidentiality
> in this step (only). The point to remember is that the term
> indicates whether you disclose identity as part of session key
> establishment.
>
> For "regular" certs (signed by a CA) the answers for the cert are:
> 1. none
> 2. none
> 3. none
>
> but for the CA key they are the same as for self-signed certs, since
> CA keys are self-signed. Note that a lot of people are treating the
> channel through which they downloaded their current browser as a
> channel with integrity, since that's the channel that distributes the
> most commonly used SA keys (for https)...
>
> So id protection imposes a requirement on IKE or equivalent, not to
> disclose the identity from the cert, if a cert is used. But it
> doesn't change the fact that the earlier steps are easier with certs
> than with preshared keys, for example backups are not such a concern.
>
> paul
>
>
References: