Subject: Re: CMP-polling

From: Peter Biltzinger <[email-masked]>
Date: Fri, 01 Oct 1999 11:14:25 +0200

Dear Amit,

> > Couldn't it be possible to start a denial-of-service attack
> > when using the current polling mechanism without SSL? Aren't
> > the following protocols conceivable?
> >
> > a)
> >
> > 1. The RA sends a signed pkiMsg to the CA and the CA sends
> >    a unsigned pollRep to the RA.
> >
> > 2. The Attacker snoops the pollingReferenceNumber and
> >    sends the unsigned pollReq to the CA (before the RA
> >    does this) and the CA sends the signed pkiMsg or
> >    the unsigned pollRep (with new pollingReferenceNumber)
> >    to the attacker.
> >
> >    In the case of sending a new pollingReferenceNumber by the
> >    CA the RA never gets this number and cannot send a pollReq
> >    which includes this new number in order to get the
> >    certificates. The communication between RA and CA is interrupt.
> >    In the case of sending a signed pkiMsg by the CA to the
> >    attacker the CA couldn't recognize the attack until
> >    the CA administrator is missing the PKIConfirmation.
> >    In both cases manual activity would be necessary to
> >    recognize and handle this attack.
> 
>         Yes, this is possible.  But manual activity is not
>         necessary.  The CA/RA can time out on a stored request
>         for which no signed confirm has been received.
> 

In the case of sending a signed pkiMsg by the CA
to the attacker you are in principle right, but
all the difficulties regarding the account between the RA and CA
are avoidable when using signed pollReq:
(1) In the case of a snooped signed pollReq the CA would
be able to recognize the attack as replay attack and
(2) in the case of a signed pollMsg signing with a wrong certificate,
    the CA would be able to recognize this also.

In the case of sending only a new pollingReferenceNumber by
the CA to the attacker, your argument regarding the missing
signed confirmation message accesses not, because the CA
expected no such message. The RA sends  a wrong
(not current) pollingReferenceNumber to CA and gets a
error message which again avoidable (by using signed pollReq)
difficulties implies.

This attack is a too easy way to disturb a CA.

> >
> > b) Even worse, if the man in the middle intercepts a RA-pollReq,
> >    he would get the signed CA-pkiMsg and could forward a
> >    new unsigned CA-pollRep with a new pollingReferenceNumber
> >    and a new 'time-to-ckeck-back' parameter to the RA.
> >    Both parties (RA and CA) would be satisfied until the
> >    CA administrator is missing the PKIConfirmation. Again,
> >    manual activity would be necessary to recognize and handle
> >    this attack.
> 
>         Yes, but again no manual intervention is necessary.
> 

The same arguments as in point a). All difficulties
regarding the account between the RA and CA
are avoidable when using signed pollReq. This attack
is also a too easy way to disturb a CA.

> >
> > c) The attacker sends unsigned pollReq with snooped
> >    old pollingReferenceNumbers or with random numbers to
> >    the CA and the CA sends signed pkiMsg or unsigned
> >    pollRep to the attacker. In the case of a hard attack
> >    of this kind the CA can be overloaded which is equal
> >    to a denial-of-service attack. (A signed pollReq would have
> >    the advantage, that the verification of the RSA signature
> >    is very much faster than the generation of the
> >    RSA signature regarding the CA-pkiMsg to be generated
> >    and perhaps to be encrypted.)
> >    Nevertheless, in the case of signed pollReq (PKIMessages which
> >    should contain the pollingReferenceNumber) the attacker can
> >    snoop a signed RA-pollReq and send this one to the CA. But in
> >    this case, the CA can verify the recipNonce in this kind of
> >    PKIMessage and would be able to recognize a replay attack.
> >
> > Are these attacks not conceivable?
> >
> 
>         The end entity not getting the new polling reference number
>         is feasible without a attack also.  Say, I send a IR, get
>         back a poll response, send a poll request, and the poll
>         response (with a new poll reference) is lost on the
>         network.  Both sides, client and server, have to be
>         aware of this and be ready to take suitable action.
> 
>         You are completely correct in that all the above attacks
>         are feasible.  However, these are denial of service attacks
>         and if someone wants to really do that, they do not have
>         to go to such pains as snooping, trying to get in the
>         middle.  I would just send tons of signed certificate
>         requests and let the server verify them and realize it
>         does not know me, wasting lots of processor bandwidth.
>         Or even send incorrectly encoded PKIMessages or even
>         signed poll requests or create TCP connections or ...
> 

In this point you are right, there are a lot of possible
denial-of-service attacks.
But a CA have to protect itself in the best way as possible. So, why
still add
further possible denial-of-service attacks?

The loss of messages in the network is possible, but this is
a rare event and must be handled. I mean a systematically
disturbance of the communication between the RA and CA
in a way, that the CA and RA cannot do their job in a
correctly and securely way over a long period with a
very high frequency of requests AND only minimal human
interventions.

Perhaps you can tell me why all messages are optional signed (depending
on
the CA policy) except the pollRep and pollReq? And why is the assignment
of new pollingReferenceNumbers intended, if the response by the CA
regarding
a pollReq is not yet finished ( in contrast to using always the same
pollingReferenceNumber regarding a given EE/RA-request )?

regards,

            Peter

----------------------------- 
Peter Biltzinger
TC TrustCenter for Security in Data Networks GmbH
Am Werder 1, 22073 Hamburg, Germany    
http://www.trustcenter.de
mailto:[email-masked]