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

Re: [Ipsec] certificate encoding type in IKEv2



Exactly.  We do this now for IKEv1.  We send all of the CA certs in the 
chain between the issuer the peer asked for and our own cert plus our own 
cert.  Each cert is in a separate payload.  The peer also may send us 
multiple CA certs in separate payloads.  We build the chain, add the trusted 
issuer CA cert we have to the chain and verify the whole thing.  There is no 
other practical way to get the intermediate CA certs in the chain.

IKEv2 has not changed this part of using certs to authenticate.

michael
Jyothi wrote:
> Hi,
> 
> Its a good point.
> If U do not  a CA certificate for the received peer certificate, we 
> cannot authenticate the peer. Then we may need to find for that CA 
> certificate in received certificates.
> 
> Regards
> Jyothi
> 
> At 07:47 PM 7/8/04 -0700, Suram wrote:
> 
>> Hi
>> I agree with you.  I have some doubts regarding the use of multiple
>> certificate payloads.  On one hand, it is clear that the first 
>> certificate
>> must correspond to the key used to sign the Auth payload.
>>
>> In this case, what would be the purpose of the other certificates?  Is 
>> there
>> any scenario where multiple certificates are used to verify the
>> authentication?
>>
>> Regards
>> Suram
>> --------- Original Message --------
>> From: Pasi.Eronen@nokia.com
>> To: vjyothi@intoto.com <vjyothi@intoto.com>, ipsec@ietf.org 
>> <ipsec@ietf.org>
>> Subject: RE: [Ipsec] certificate encoding type in IKEv2
>> Date: Thu 07/08/04 12:34 AM
>>
>> >
>> >
>> > Hi,
>> >
>> > IKEv2 Section 3.6 says that
>> >
>> >    "Implementations MUST be capable of being configured to send
>> >    and accept up to four X.509 certificates in support of
>> >    authentication.  Implementations SHOULD be capable of being
>> >    configured to send and accept Raw RSA keys and the first two
>> >    Hash and URL formats."
>> >
>> > This MUST requirement seems to refer to the "X.509 Certificate -
>> > Signature" type; so you answered your own question :-).
>> >
>> > The possible ambiguity concerning "PKCS #7 wrapped X.509
>> > certificate" type is resolved by draft-ietf-pki4ipsec-ikecert-
>> > profile-00: it says that "Implementations SHOULD NOT generate
>> > CERTs that contain this type".
>> >
>> > If you have a certificate chain, then you use several
>> > CERT payloads (note that they do not have to be in order,
>> > except the first one must correspond to the key used
>> > to sign the AUTH payload). Certificate bundle is just a set
>> > of certificates, not necessarily in any special order. I guess
>> > usually a bundle will contain at least one chain.
>> >
>> > Best regards,
>> > Pasi
>> >
>> > -----Original Message-----
>> > From: ipsec-bounces@ietf.org On Behalf Of vjyothi@intoto.com
>> > Sent: Wednesday, July 07, 2004 9:02 AM
>> > To: ipsec@ietf.org
>> > Subject: [Ipsec] certificate encoding type in IKEv2
>> >
>> > Hi all,
>> >
>> > In draft-ietf-ipsec-ikev2-14.txt, section 3.6 following certificate
>> > encoding types are defined:
>> >
>> >            PKCS #7 wrapped X.509 certificate    1
>> >            PGP Certificate                      2
>> >            DNS Signed Key                       3
>> >            X.509 Certificate - Signature        4
>> >            Kerberos Token                       6
>> >            Certificate Revocation List (CRL)    7
>> >            Authority Revocation List (ARL)      8
>> >            SPKI Certificate                     9
>> >            X.509 Certificate - Attribute       10
>> >            Raw RSA Key                         11
>> >            Hash and URL of X.509 certificate   12
>> >            Hash and URL of X.509 bundle        13
>> >
>> > I would like to what is MUST in above defined types.
>> > In IKEv2, it is X.509 certificate-signature.
>> >
>> > I would also like to know what is cert bundle which is defined in
>> > page 58. Is it related to certificate chain??
>> >
>> > How can we use certificate chains in IKEv2??
>> >
>> > Many thanks in advance,
>> > Jyothi
>> >
>> > _______________________________________________
>> > Ipsec mailing list
>> > Ipsec@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/ipsec
>> >
>> >
>> >
>> >
>>
>>
>> _______________________________________________
>> Ipsec mailing list
>> Ipsec@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipsec
> 
> 
> 
> _______________________________________________
> Ipsec mailing list
> Ipsec@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipsec

-- 
---- ---- ----
Michael Reilly    michaelr@cisco.com
     Cisco Systems,  California

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec