Subject: CMP-polling

From: Peter Biltzinger <[email-masked]>
Date: Mon, 27 Sep 1999 15:34:21 +0200

Regarding the  RFC 2510 (CMP) arises a question on the
polling-mechanism. As I understand the RFC 2510, there
is no possibility to sign the TCP/IP messages, which contain
the pollingReferenceNumbers - special the polling-request (pollReq).

The consequence of this polling-mechanism is that an attacker
can send pollinReferenceNumbers (with random numbers or systematically)
to the CA in order to get informations of the CA/RA customer. This is a
problem
in the context of closed user-groups and in the context of customers,
who have
certificates, which are public for downloading but general are
non-public.
Furthermore it is possible to interrupt the CMP-protocol between RA and
CA.
32-bit polling-numbers are not really protect the RA/CA from this
attacks.

Are there any mechanisms regarding the RFC 2510 to authenticate the
polling-requests, pollReq, (apart from a SSL-connection), or should
the RFC 2510 be modified in this point, perhaps by introducing a new
type
of  DER-encoded, signed CMP-Message (CMP-Polling-Requst)
to send the polling-request?

Regards,
                     Peter

--
Dr. Peter Biltzinger                   mailto:[email-masked]
TC TrustCenter                         http://www.trustcenter.de
for Security in Data Networks GmbH     Phone: +40-7 66 29 28 05
Am Werder 1, 22073 Hamburg, Germany    Fax:   +40-7 66 29 5 77
--

---

From: "Amit Kapoor" <[email-masked]>
Date: Mon, 27 Sep 1999 13:17:59 -0700

Hi Peter,

> the pollingReferenceNumbers - special the polling-request (pollReq).

	Please take a look at the draft CMP-over-TCP as there
	have been some changes due to interoperablility testing
	done by some implementors.

> problem in the context of closed user-groups and in the context of
customers,
> who have certificates, which are public for downloading but general are
> non-public. Furthermore it is possible to interrupt the CMP-protocol
between RA and
> CA. 32-bit polling-numbers are not really protect the RA/CA from this
> attacks.

	A closed-group CA can be shutout from the outside poll requests.

	A open/general CA issuing non-public certificates in the open
	has the general problem that the clear data can be snooped.  So
	you would have to encrypt the channel itself and that is different
	from having a signed poll request.  You have the choice of SSL or
	CMC etc. for that.  Would this work?

	In the case of a open/general CA, the the attacker can
	get the response to a certificate request, but it still needs
	to send a signed confirm/reject to change the state on the
	server side.  But this does bring up a good point and that
	is the CA/RA should not change the state of the request on
	pollReq and only on signed PKI messages.  We will add this
	clarification to the draft protocol document.

	regards

Amit

---

From: Peter Biltzinger <[email-masked]>
Date: Wed, 29 Sep 1999 17:29:05 +0200

Dear Amit,

thanks for your mail.

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.

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.

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?

Regards,

         Peter

--
Peter Biltzinger                      mailto:[email-masked]
TC TrustCenter                         http://www.trustcenter.de
for Security in Data Networks GmbH     Phone: +40-7 66 29 28 05
Am Werder 1, 22073 Hamburg, Germany    Fax:   +40-7 66 29 5 77
--

---

From: "Amit Kapoor" <[email-masked]>
Date: Wed, 29 Sep 1999 12:20:18 -0700

Hi Peter,

>    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.

>    manual activity would be necessary to recognize and handle

	Yes, but again no manual intervention is necessary.

> 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 ...

	My point in my earlier message was to see if I had understood
	your concern on sending certificates with sensitive information
	in the clear.

	regards

Amit

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 29 Sep 1999 17:10:58 -0400

What is the difference between the following two structures:

::= SEQUENCE SIZE (1..MAX) OF

::= SET OF

To the casual reader they are both a collection of one or more thingees.

Unless SET implies an empty set so that 

SET == SEQUENCE SIZE (0..MAX) OF

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

---

From: "Ambarish Malpani" <[email-masked]>
Date: Wed, 29 Sep 1999 14:44:02 -0700

Hi Bob,
    Not sure if I am stating the obvious, but SEQUENCEs and
SETs are slightly different things in ASN.1, where a sequence
is an ordered bag of things, while a set is unordered (also, their
encoding is different).

In practice, I am not sure people in PKIX-land distinguish
between the two other than to make sure the DER/BER encoding is
correct.

A

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: Robert Moskowitz [mailto:[email-masked]]
> Sent: Wednesday, September 29, 1999 2:11 PM
> To: [email-masked]
> Subject: ASN.1 question on 2459
> 
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 30 Sep 1999 09:24:49 -0400

>::= SEQUENCE SIZE (1..MAX) OF
Thank you all of you that answered.

In 2459, SET seems to be used only in Name things.  SEQUENCE SIZE is used
most of the time, and it always starts with 1..

But some of them are 'optional':

        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                PolicyQualifierInfo OPTIONAL }

Again this is a bit confusing to the casual reader.  The only LOGICAL
interpretation is a SEQUENCE of SIZE 0 is different in the cert than not
present and this is desireable.  OK.

Some of this stuff is wicked.

Robert Moskowitz
ICSA