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

RE: Certificate Requesting



All,

Let me try to clear up the whole issue surrounding ISAKMP and
Certificate Requesting.

It was initially added for the purpose the text in section 3.10
states:

	"Certificate Request payloads SHOULD be included in an exchange
	whenever an appropriate directory service (e.g. Secure DNS
	[DNSSEC]) is not available to distribute certificates"

It's inclusion was a "poor man's" certificate retrieval approach (to be
used until such time as directories, etc. were available). It was never
meant to be a "fully functional" certificate management component.

However, the text in section 3.10 is unclear. Ted was correct in his
interpretation of the text and effectively a CertReq payload could be
sent by the responder in the last message of the exchange, thus,
extending the exchange. It was NEVER intended to be used in this
manner. Tero has captured the problem with the "never-ending"
certificate request message exchanges example.

As stated previously, the initial intent was to have the CertReq
payload within the context of the given exchanges (not including the
last message from the responder). The reason, from a security
standpoint, is captured by Dan in his message below. That having been
said, I'm willing to:

(a) write clarifying text to make sure there is no misunderstanding
about when a CertReq payload is included in the exchange (i.e. anytime
before the last message from the responder). NOTE: This is my
preference and we can state that a Key Exchange (IKE, et. al.) can
extend the exchange model if they so desire.

OR 

(b) change to the text to include the capability to continually extend
the exchange (which I don't really like).

OR

(c) something different.

What say ye??

Doug


> 
> Roy Pereira writes:
> > The additional exchange scenario that you do not agree with only happens
> > if the initiator does not send a certificate and the responder does not
> > have it.  The responder will then append a CertReq payload to the ISAKMP
> > message.  If the initiator receives the CertReq in the sixth message of
> > MainMode (RSA_SIG), then he must reply back with his certificate in a
> > MainMode message.  He may also append a CertReq to that message if the
> > responder did not include a certificate in the sixth message and he does
> > not have it.  This would force the responder to reply back with his
> > certificate.
> 
> Tero Kivinen writes:
> And if responder again includes certificate request (it can, there is
> no limitation that there must be only one of certificate request) the
> initiator must again reply to it and so on. Is there any limit for
> this?
> 
> I can see that someone might want to use this kind of system when they
> don't want the other end even to know what CA's they need. They could
> first ask can you provide certificate for this CA, and if so they know
> OK, now it is ok to ask next level of CA etc.
> 
> I really don't like the exchange to be extended this way. I would
> really like to explicitly say that certificate requests are only
> allowed if the other end is going to reply this message anyway. You
> can also expand the exchange from normal six or three messages if you
> set commit bit. 
> 
> > This scenario was brought forth by a rather large software corporation
> > since this is what they do in their IPSec implementation.
> 
> Is there really any real use for this? It makes the state machine even
> more complicated than it is now, and the there are quite a lot of
> different stuff there already given all the different authentications,
> aggressive/main mode, commit bit etc. 

 
> 
> Dan Harkins writes:
>   Perhaps I'm missing something here but you're asking for the cert's
> too late. You need them to verify the signature but you're not asking
> for them until you've already, presumably, authenticated your security
> association by checking the peer's signature.
> 
> >>        Initiator                          Responder
> >>       ----------                         -----------
> >>        HDR, SA                     -->
> >>                                    <--    HDR, SA
> >>        HDR, KE, Ni                 -->
> >>                                    <--    HDR, KE, Nr
> >>        HDR*, IDii, [ CERT, ] SIG_I -->
> >>                                    <--    HDR*, IDir, [ CERT, ] SIG_R[,
> >>CERTREQ 
> >>        [ HDR*, CERT [, CERTREQ]          --> 
> >>				    [<--    HDR*, CERT ] ] ]
> >>  
> 
> If the Initiator didn't send his cert in his 3rd message then the
> responder wouldn't be able to verify his signature and would abort
> the communication. Why not send a CERTREQ in the 2nd messages. That
> way you're still keeping a modicum of identity protection (sending it
> in the 1st messages requires the other party to respond with his cert
> in the clear). 
> 
> At the point you're sending the KE and nonce payloads you know what your
> authentication method is. If it's signature based and you don't have a
> cert for the peer (granted it's tough to know if you do since all you have
> to go on at that point is IP address and not everyone will be encoding an
> IP address in their certs) send the CERTREQ then.
> 
> Why the need for the extra round trip? And the suspension of authentication
> and retention of state? Am I missing something here?
> 



> Greg Carter writes:
> >----------
> >From: 	Theodore Y. Ts'o[SMTP:tytso@MIT.EDU]
> >Sent: 	Monday, February 23, 1998 12:51 PM
> >To: 	Greg Carter
> >Cc: 	'Theodore Y. Ts'o'; 'IPSEC Mailing List'; 'Dan Harkins'; 'RoyPereira'
> >Subject: 	Re: Certificate Requesting
> >
> >   From: Greg Carter <greg.carter@entrust.com>
> >   Date: Sun, 22 Feb 1998 14:51:49 -0500
> >
> >   I would not interpret this to mean that I can arbitrarily extend the
> >   exchange. There is plenty of opportunity to send the cert request during
> >   the defined exchange. 
> >
> >The text I quoted is from the ISAKMP document; within the context of
> >ISAKMP, there can be an arbitrary number of round-trips.  IKE rides on
> 
> Hi Ted,
> Can you point me to where in ISAKMP that it states arbitrary number of
> round trips are allowed?  All I could find was text to the contrary.
> 
> >From Section 2.1
> 
> Exchange Type - An exchange type is a specification of the number of
> messages in an ISAKMP exchange, and the payload types that are contained
> in each of those messages.
> 
> What's the purpose of specifying the number of messages in an exchange
> if the number can be arbitrarily modified?


Follow-Ups: