[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Certificate Requesting
There appears to be plenty of opportunity for a responder (even more
for the initiator) to send a Cert Req in both the Identity Protect
Exchange and in the Aggressive Exchange to support the timely
exchange of Certs. As for extending an Exchange (?) is there any real
need :-
Generally Phase1 will be followed directly by a Phase 2, the first
phase 2 message effectively completeing the Phase 1 exchange - no
need for a notify i.e. to extend the exchange.
In the case where a Phase 1 ISAKMP-SA is about to expire and the
entities wish to maintain a secure ISAKMP channel between them - but
do not intend to establish a security protocol SA immediately - then
would it not be more efficient to establish an ISAKMP-SA under the
protection of the existing one. If done this way no certificates have
to be exchanged, PFS would not be a problem since new DH values would
still be exchanged as defined.
As for the Quick Mode exchange, the initiator (if it wishes) has
enough opportunity to request and receive a Cert. The Responder on
the otherhand only has the opportunity to request and receive the
Cert but not to acknowledge that it accepted the Cert and the SA has
been established. I dont see this as a problem for Host
implementations - they have ID'd and Auth'd themselves in
Phase1. However, if proxying different Certs will need to be
exchanged. If the responder Cert processing fails the Responder
should trash the SA, then either send no notify or notify the
proxying agent (under the protection of the ISAKMP-SA) that a phase 2
SA with Message ID = x failed. No need to extend the Exchange here
either.
It seems a simple modification of text, as suggested by wdm below, is
adequate when combined with some text stating that exchanges MUST not
be extended under any circumstances.
> Date: Tue, 24 Feb 98 06:54:15 EST
> From: wdm@epoch.ncsc.mil (W. Douglas Maughan)
> To: rpereira@TimeStep.com, dharkins@cisco.com, greg.carter@entrust.com,
> tytso@MIT.EDU, kivinen@ssh.fi
> Subject: RE: Certificate Requesting
> Cc: ipsec@tis.com, wdm@epoch.ncsc.mil
> 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?
>
>
****************************************************
"The views expressed above are entirely those of
the writer and do not represent the views, policy or
understanding of any other person or official body."
Elfed T. Weaver
DERA
Malvern
UK
weaver@hydra.dra.hmg.gb
****************************************************
Follow-Ups: