[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New CMC Draft available
I would like to stress the initial registration procedure (section 5.3).
Thanks to the authors and contributors for CMC review and improvement.
But I have still a concern. Unless otherwise stated initial registration
protocols defined in CMC and CMP are considered.
Supposed that the initial registration message is not encrypted,
off-line guessing attacks may appear. The weakness comes from the fact
that the input data (plaintext) for the HMac algorithm is sent together
with its cipher text. The adversary may confirm before the CA or RA
receives the message. The probability of guessing the initial
authentication key is nearly one if the adversary has enough time.
There are the following three consequences:
1) The initial authentication key is only suitable for short-term usage.
2) Supposed an adversary can intercept the connection to the CA or RA
the adversary can reformulate entity´s certificate request.
3) An adversary can apply for a certificate with changed request data
even if he is not able to intercept the connection between end entity
and CA.
The initial authentication key distribution is commonly a cost-intensive
procedure. I assume for the following that the initial authentication
key is an identifier for the individual entity. It might be a good idea
to use this initial authentication key for further off-line
authentication procedures e. g. certificate revocation request.
I consider for example that the adversary may replace entity´s public
key by its own. The following cases may be considered:
Case 1. I assume that the adversary can intercept any connection between
the certificate applicant and the CA. The CA issues a certificate that
contains applicant´s identity and adversary´s public key. The applicant
may miss his certificate but he may think that is an operational issue.
The concerned entity may phone on the CA. Consequently, cost-intensive
back office procedures have to start. CMP users are in the comfortable
position that they have to be silent when they do not confirm. In the
meantime the adversary can confirm whereby he applies the initial
authentication key again. The adversary has probably a fake certificate
for the whole validity period. (Note: If there is no control over
initial authetication key expiry in the CA domain the entity may
re-certified in addition. But the adversary has still a fake certificate
containing entity´s identity and adversary´s public key.) I propose to
add a message to both the CMP and CMC protocol that allows the applicant
to retrieve the certificate after a time-out specified by local policy.
The response then contains the issued certificate, a waiting or an error
message. Now the applicant can validate the received certificate and
send his confirmation. The validation must include a check that the
public key in entity´s
certificate matches entity´s private key. Additionally, I propose an
explicite non-confirmation message.
Case 2. I assume that the adversary is not able to intercept the
connection between the CA and the end entity. Depending on the controls
implemented by the CA no, one or two certificates will be issued. The CA
will detect the attack when it takes appropriate control over the
initial authentication key management. The initial authentication key
must be a unique and one-time password that corresponds to an individual
entity. Nevertheless the end entity must validate that the issued
certificate contains the public key matching entity´s private key.
Therefore an explicit non-confirmation message would be meaningful.
A security measure against this offline-guessing attack is the
encryption of the initial registration. Please add an appropriate
recommendation to the CMC and the CMP draft.
There are initial registration protocols that provides a higher level of
security. For example the HMac is taken over data that is not completely
known by a potential adversary. Then he is not able to verify his guess
because he does not know the complete plain text. In the case of
signature algorithms with message recovery the certificate applicant may
include a self-choosen password that is contained in HMac input as plain
text. But this password is contained in the initial registration request
as cipher text where it is encrypted by e. g. CA´s public key. The
password is not contained as plain text in the initial registration
request at all. This password chosen by the entity may serve for
authentication purposes in revocation requests. Unfortunately the schema
is not applicable for signature algorithms like DSA. It has to be
re-designed. Replace the one-directional delivery of an initial
authentication key prior to the initial registration by an out-of-band
exchange of keys or passwords i. e. the following out-of-band procedures
take place before an end entity sends his initial registration message:
CA->EE: initial authentication key, other initial data
EE->CA: password
This causes no additional expenses in such registration scheme where the
end entity is well-identified by some agent. Nowadays it is commonly
applied by GSM phone sellers.
I think that the current CMP and CMC draft does not support the scheme
described above. Is a support of the described scheme planned for next
CMP and CMC reviews? Is someone else interested in such scheme?
Juergen
Carlisle Adams wrote:
>
> Hi,
>
> > ----------
> > From: Jim Schaad (Exchange)[SMTP:jimsch@exchange.microsoft.com]
> > Sent: Monday, March 08, 1999 1:12 PM
> > To: IETF-PKIX (E-mail)
> > Subject: New CMC Draft available
> >
> > A new draft of CMC (what will become draft -03) is now available on-line.
> > This draft should appear on the various IETF servers shortly after the
> > upcoming meeting in Minneapolis. We apologize for missing the
> > internet-draft cutoff date to get the draft published on IETF servers
> > before
> > the meeting; in the meantime the draft is available in various format from
> > Brian LaMacchia's personal website at:
> >
> > http://www.farcaster.com/cmc/
> >
> > The differences between the -02 and -03 drafts may be summarized as
> > follows:
> > 1) New Section 5.3, Linking Identity and POP information, to address the
> > potential theft/replay attack involving cert requests with NULL subject
> > DNs
> > that Carlisle Adams pointed out.
> > 2) Revised Section 5.7, POP for Encryption-only Keys, to address a similar
> > attack involving the example state-reduction technique.
> > 3) Numerous editorial changes that were made in response to comments
> > posted
> > to the list and/or delivered to the authors privately.
>
> Congratulations to all authors and contributors on this revision; the
> improvements over the previous draft are significant! In particular, it
> appears that the modifications to Sections 5.3 and 5.7 address my earlier
> concerns so that an entity may now be securely initialized into the PKI
> using this protocol.
>
> I have a few additional comments but, in order to save bandwidth on the
> list, perhaps I'll send the minor editorial ones (typos, wording
> clarifications, etc.) privately to the authors. The rest are included
> below.
>
> Abstract: there is not a *need* for an interface to PK certification
> products and services based on [CMS] and [PKCS10]; there is a *desire* for
> such an interface. Nothing *needs* to be based on CMS and PKCS10
> (especially since, as noted in the conformance section, existing deployed
> software is not immediately compliant with this specification). However,
> there is great *desire* to base the protocols on CMS and PKCS10, since these
> are familiar. Please change "need" in bullet 1 to "desire" (and change
> "immediate needs" in the opening sentence to "immediate concerns", or
> similar).
>
> Section 2, Section 2.1, and elsewhere: the document sometimes uses
> "certificate authority", sometimes uses "certification authority", sometimes
> uses "Certification Authority", and so on. Please be consistent throughout.
> [Note that "Certification Authority" is the official term in various
> Standards.]
>
> Section 2: this may be obvious to many, but I think that stating the
> following underlying operational assumption will help to clarify the
> operational model for this protocol. "Underlying assumption: every PKI
> entity will have a signing key pair and will request a verification
> certificate in its initialization message (i.e., an entity will never ask
> for an encryption certificate _only_ in its initialization message)." [The
> reason that it might help to clarify this is that RFC 2510 does not have
> this restriction.]
>
> Section 3.3.3.1: "D-H private keys cannot always be used..." -- note that
> is may also be true for RSA keys that are held in a decrypt-only device, so
> you need not restrict this section to D-H.
>
> Also, "NoSignatureValue contains the hash of the certification request." --
> why force the implementer to do an extra hash here for no purpose? Why not
> say that NoSignatureValue "contains the value 1234", or similar?
>
> Section 5.2 (second paragraph): "Servers SHOULD provide this method or have
> a bilateral method..." -- I would prefer the following for interoperability
> reasons: "Servers MUST provide this method and MAY also have a bilateral
> method...".
>
> Section 5.7: should note in first paragraph that PKCS10 cannot be used to
> provide this functionality.
>
> Also, it appears (from the text in bullet 4a and the text in the second-last
> sentence of the section) that the DecryptedPOP structure should contain
> "request TaggedRequest" rather than "bodyPartID BodyPartID". That is,
> the decrypted POP needs to contain the actual request itself (not just an
> ID).
>
> Section 5.9 (last paragraph): "the server responds with a Key Recovery
> Response containing the newly generated key." -- it doesn't really make any
> sense semantically to use a key recovery response to implement off-client
> key generation (since off-client key generation is not key recovery). Why
> not simply define a new message ("OffClientKeyGenRep") with the same syntax
> as Key Recovery Response?
>
> Also, "The details of the request control statement not covered in this
> document...". This will limit the use of this protocol in some environments
> (those that mandate central key gen.). A request message needs to be
> defined for this purpose.
>
> Section 5.9.3: "The ContentInfo contains the requested private key
> material." -- does it also contain the newly-created recipient (i.e., EE)
> certificate? If not, how can this response be used for off-client key
> generation? [Note that according to CMS, it is not clear that it's legal
> for a CA to put the EE certificate in this construct....]
>
> Sections 5.9.4.1, 5.9.4.2, 5.9.4.3: in each section you need to say that
> the private key (DH-PrivateKey, DSA-PrivateKey, or RSAPrivateKey) must
> subsequently be re-encoded as an OCTET STRING (in order to fit within the
> structure defined in Section 5.9.4).
>
> Section 5.10: "low-end IP router that does not retain its own certificate
> in non-volatile memory". I might prefer "low-end IP router that does not
> retain in non-volatile memory the certificates of those entities with whom
> it needs to communicate". Entities certainly need to get the certificates
> of others in order to talk with them; do they really need to keep their own
> certificates for most of their activities?
>
> Section 5.11: "The fields in a GetCRL have the following meanings: --
> issuerName is the value of the Issuer DN in the subject certificate." This
> will not work for Indirect CRLs. Perhaps this field should hold the name of
> the CRL issuer instead...
>
> Section 5.12: "it is impossible to produce a reliable digital signature."
> -- this should be clarified to "it is impossible to produce a reliable
> digital signature (prior to the certification of a new signature key pair)."
>
> Section 5.14: "The query pending attribute allows for a client to query a
> server about the state..." -- how does the client know when to do this? Is
> there a time-to-check-back value included somewhere in the server's
> response?
>
> Section 6.1: "The request is placed in the cmsSequence if it is a full pki
> message and the reqSequence field for a simple enrollment message." -- in
> the latter case, is this still a nested message? (I.e., what is the
> difference between a "non-nested" message with a PKCS10 in the reqSequence
> and a "nested" message with a simple enrollment message in the reqSequence?)
>
> Sections 7.2, 7.3: replace "BER" with "DER" since signatures are
> involved...
>
> Section 12: update the CRMF reference to RFC 2511 and the PKIXCERT
> reference to RFC 2459. Also, was DH-SIG not updated to some other draft
> recently?
>
> Finally, there is some functionality missing in this specification that
> will be very important for some environments.
>
> - there is currently no way for a CA/RA to provide a trust anchor (public
> key or self-signed cert) to the client during initialization.
>
> - there is no confirmation message from the client to the CA/RA (thus, there
> is no way for a client to reject a certificate that it does not want (e.g.,
> in the case where the CA has modified some of the fields in the request)).
>
> - cross-certification is not described. (It appears to be possible to do
> this with the existing messages, but without a prescribed method
> interoperability is unlikely.)
>
> - as mentioned above, off-client key generation needs to be specified (both
> request and response). It would also be nice to be able to ask for this as
> part of the Full PKI Request message, rather than having to use separate
> req/rep messages.
>
> - CA key rollover is not described. (This might be considered to be
> out-of-scope of the current document, but it is very much in-scope for a
> specification on how to do comprehensive certificate management, which is
> what the title of this document suggests.)
>
> That's all. Aside from a few other typos, etc., the document looks great!
>
> Carlisle.
--
with regards
--------------------------------------------------------------------
Juergen Walter PoP Leipzig/Halle/Jena
DEH information systems GmbH WWW: http://www.deh.de
Weissenfelser Strasse 46a Germany
D-06217 Merseburg Tel.: +49 3461 3318-25
Email: walter@deh.de Fax: +49 3461 415072
--------------------------------------------------------------------