[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IKEv1: use of CERTREQ



I think that I misunderstood number 3). I was thinking that a
device must announce trusted cross-certified CAs. It seems
that it is enough that it announces only the trusted root CA.

> -----Original Message-----
> From: ext Brian Korver [mailto:briank@briank.com]
> Sent: 28 October, 2003 08:03
> To: Ollila Juha (NET/Oulu)
> Cc: ipsec@lists.tislabs.com
> Subject: Re: IKEv1: use of CERTREQ
> 
> 
> juha.ollila@nokia.com wrote:
> > 
> >         Hello all,
> > 
> > The usage of CERTREQs is not very well specified. I know that there
> > is a pki-profile draft.
> > 
> > Two IKE implementations want to negotiate security associations.
> > Let's assume the following:
> > - There are two security domains
> > - Each domain has own CA
> > - CAs has cross-certified each other
> > - IKE implementations belong different security domains i.e.
> > they have not peer's certificate.
> > 
> > What is the *current practice* in this situation?
> > 
> > There are at least 4 possibilities, when certificate based
> > authentication is used in IKE:
> > 
> > 1) IKE does not send a CERTREQ at all
> > - This contradicts with the pki-profile draft, because in-band
> > exchange of certificates is desired.
> > 
> > 2) IKE sends an empty CERTREQ
> > - This contradicts with the pki-profile draft.
> > 
> > 3) Several CA names are configured and IKE sends multiple CERTREQs
> > - This has privacy problem, if security domains don't want to
> > reveal their trust relationships.
> > 
> > 4) CA name is configured for each ISAKMP policy and IKE send one
> > CERTREQ
> > - Is this supported in the current implementations?
> > 
> > BR,
> > Juha Ollila
> 
> Agreed on 1 & 2.  I don't really understand 3, as the devices
> are in different security domains and thus will only be configured
> to trust their (presumably one) local CA.  So, #4 sounds right, and
> I can even tell you that at least one of Nokia's implementations
> works that way.
> 
> -brian
> briank@briank.com
>