CMP authentication

[Juraj Michalak]

Hello,

I created CMP session (CRYPT_REQUESTTYPE_INITIALIZATION) to obtain
certificate from CA. In my project I have used EJBCA
(http://www.ejbca.org) as CA. I have created end user with password in
EJBCA. I have set that user and password on my cryptlib CMP session and
activated it... -> error ...

Problem:
========
In EJBCA logs I can see that there is problem with user authentication.
EJBCA is expecting authentication via regToken attribute in
CRMF->CertRequest->Controls (it is only supported auth. by EJBCA).

With use of wireshark I have found that cryptlib sends in that CMP
session only PBM (Password Based Mac), where is used USERNAME previously
set on that cryptlib CMP session. So I believe that cryptlib uses PBM
for authentication.

QUESTION:
=========
What can I do? I'm so far with my project. Till now I have used only
those dummy self signed certificates (CRYPT_CERTINFO_XYZZY) or imported
certificates.

PS:
==
I have seen that there are some questions about importing from different
formats (PEM, PKCS12). And I think that better answer could be:
Let's use openssl to covert any certificate into .der format, which can
be imported easily by cryptCertImport(...):

openssl x509 -inform PEM -in cert_in_pem_file -outform DER -out
converted_cert_in_der

(for other usage - openssl x509 help)

PS2:
====
If you are curious/interested - my project (quotation of cryptlib's
manual is also there, it is short article for out faculty conference):
http://student.fiit.stuba.sk/~michalak04/zdielane/Michalak_iit-src2009.pdf

best regards

Juraj Michalak


_______________________________________________
Cryptlib mailing list
Cryptlib@... via Mail: cryptlib-request@...
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.

[Peter Gutmann]

Juraj Michalak <juraj.michalak@...> writes:

>I created CMP session (CRYPT_REQUESTTYPE_INITIALIZATION) to obtain
>certificate from CA. In my project I have used EJBCA (http://www.ejbca.org)
>as CA. I have created end user with password in EJBCA. I have set that user
>and password on my cryptlib CMP session and activated it... -> error ...
>
>In EJBCA logs I can see that there is problem with user authentication. EJBCA
>is expecting authentication via regToken attribute in
>CRMF->CertRequest->Controls (it is only supported auth. by EJBCA).

How does it authenticate the CMP exchange then?  It needs either a MAC or a
signature, and you can't sign at that point because you don't have a
certificate.  The regToken isn't meant to be used for this, AFAIK it was some
Entrust thing based on their one-time pasword tokens that no-one else ever
used (or even knew what to do with, for that matter).

>What can I do? I'm so far with my project. Till now I have used only
>those dummy self signed certificates (CRYPT_CERTINFO_XYZZY) or imported
>certificates.

If EJBCA doesn't implement CMP properly then you'd have to use a proper
implementation on the CA side.

(A caveat about CMP, the protocol is such a mess that it's more or less just
blind luck to find two independent implementations that interoperate.  See the
bit about halfway through "Plug-and-play PKI: A PKI your mother can use"
linked off my home page for just a small taste of some of the problems).

Peter.

_______________________________________________
Cryptlib mailing list
Cryptlib@... via Mail: cryptlib-request@...
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.

[Tomas Gustavsson-3]

Hi Juraj and Peter,

I'd be glad if you directed EJBCA specific questions to the EJBCA
mailing list or forums. That would avoid misunderstandings about how
EJBCA works or not. It's pretty well documented at EJBCA.org, although
some clarification can always be done if it's not clear enough.

I completely agree with Peter that CMP is a total mess. This protocol is
not designed for interoperability, that is clear.

I usually recommend people looking for a CMP client in C to look at
cryptlib, since I have tested it myself that EJBCA and Cryptlib is
compatible (you may remember some email a few years back Peter).

EJBCA can handle CMP request authentication in two ways.

1. Using "RA mode", a shared secret is used to authenticate CMP messages
using HMAC. This is the way all products I have seen uses CMP. It is
usually smart card management systems acting as an "RA" to EJBCA. Using
the shared secret HMAC authentication the RAs can request certificates.

This is well tested against cryptlib!

2. If not using "RA mode" an individual user can be authenticated using
a one-time password in the CRMF message (not in the CMP message)
"Registration token control id-regCtrl-regToken". This is pretty well
specified in RFC 4211 section 6.1. Is it really an Entrust think?. It
seems pretty well specified to me?
"When deciding whether to use an authenticator or a regToken, use the
following guidelines. If the value is a one-time usage value, then
regToken would be used. If the value has a long-term usage, then the
authenticator control would be used."

According to RFC4211 the regToken is used specifically for this:
"A regToken control contains one-time information (either based on a
secret value or other shared information) intended to be used by the
CA to verify the identity of the subject prior to issuing a
certificate."

Using MAC authentication for users is not good since it requires the CA
to keep the users password in clear text.

Is it not possible to use a regToken in CRMFs with Cryptlib?
(I can't recall I did test exactly this).

Kind regards,
Tomas

Peter Gutmann wrote:

> Juraj Michalak <juraj.michalak@...> writes:
>
>> I created CMP session (CRYPT_REQUESTTYPE_INITIALIZATION) to obtain
>> certificate from CA. In my project I have used EJBCA (http://www.ejbca.org)
>> as CA. I have created end user with password in EJBCA. I have set that user
>> and password on my cryptlib CMP session and activated it... -> error ...
>>
>> In EJBCA logs I can see that there is problem with user authentication. EJBCA
>> is expecting authentication via regToken attribute in
>> CRMF->CertRequest->Controls (it is only supported auth. by EJBCA).
>
> How does it authenticate the CMP exchange then?  It needs either a MAC or a
> signature, and you can't sign at that point because you don't have a
> certificate.  The regToken isn't meant to be used for this, AFAIK it was some
> Entrust thing based on their one-time pasword tokens that no-one else ever
> used (or even knew what to do with, for that matter).
>
>> What can I do? I'm so far with my project. Till now I have used only
>> those dummy self signed certificates (CRYPT_CERTINFO_XYZZY) or imported
>> certificates.
>
> If EJBCA doesn't implement CMP properly then you'd have to use a proper
> implementation on the CA side.
>
> (A caveat about CMP, the protocol is such a mess that it's more or less just
> blind luck to find two independent implementations that interoperate.  See the
> bit about halfway through "Plug-and-play PKI: A PKI your mother can use"
> linked off my home page for just a small taste of some of the problems).
>
> Peter.
>
> _______________________________________________
> Cryptlib mailing list
> Cryptlib@... via Mail: cryptlib-request@...
> Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
> http://news.gmane.org/gmane.comp.encryption.cryptlib
> Posts from non-subscribed addresses are blocked to prevent spam, please
> subscribe in order to post messages.

_______________________________________________
Cryptlib mailing list
Cryptlib@... via Mail: cryptlib-request@...
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.

[Peter Gutmann]

Hi,

>I'd be glad if you directed EJBCA specific questions to the EJBCA mailing
>list or forums. That would avoid misunderstandings about how EJBCA works or
>not. It's pretty well documented at EJBCA.org, although some clarification
>can always be done if it's not clear enough.

Oh, sorry, I didn't know this was going to anyone involved with EJBCA, I was
just responding to a general message on the cryptlib list...

>I usually recommend people looking for a CMP client in C to look at cryptlib,
>since I have tested it myself that EJBCA and Cryptlib is compatible (you may
>remember some email a few years back Peter).

Yeah, that's why I was a bit puzzled, I thought maybe EJBCA had changed
something which had broken things, thus the (somewhat unjustified, sorry)
"proper implementation" comment.

>2. If not using "RA mode" an individual user can be authenticated using a
>one-time password in the CRMF message (not in the CMP message) "Registration
>token control id-regCtrl-regToken". This is pretty well specified in RFC 4211
>section 6.1. Is it really an Entrust think?. It seems pretty well specified
>to me?

Well, you have to know the history of CMP :-).  It was originally an Entrust-
internal protocol that was proposed as an IETF standard.  After eleven
rewrites it ended up as CMPv1.  The interop testing for that was that "this
protocol does not work", so it was kludged into CMPv2 (this is why the RFC
started with v2 even though there was never officially a v1).

The results of the second attempt at interop testing were so bad that they
were never published.  After that the authors of the RFCs abandoned them (for
the 25xx ones) and completely new authors stepped in to do the 42xx versions
who AFAIK weren't involved in the 25xx fiasco, because there were some edits
made in 42xx that made things rather more murky than they already were, and
several of the (non-)interop results that should have gone into any new
version were never added.

Anyway, one of the artefacts of the CMP origins is that there are lots of
remnants in there that made sense to Entrust but not to anyone else (the
original interop notes make interesting reading, I think I quoted some of them
in the "PnP PKI" paper, things like "What does XYZ do?  Why is it there?  What
problems does it solve?".  The really scary thing is that there are things in
there that even the original RFC authors couldn't explain, when asked).

Anyway, regToken is one of the makes-sense-to-Entrust things, I heard from
another vendor during the first round of (non-)interop tests that Entrust had
some sort of OTP token that they used with CRMF requests, and regToken was
used to contain the OTP value.  Since no-one else had any idea what to do with
this value, no implementation (that I know of) made any use of it.

>Is it not possible to use a regToken in CRMFs with Cryptlib? (I can't recall
>I did test exactly this).

No, for two reasons, first there's no indication of how this would be used.
Now admittedly you can say the same for a lot of the rest of CMP but at least
there was some consensus about what to do with the various fields during the
interop attempts, with regToken you'd be more or less creating a proprietary
implementation.

A far more serious problem though is that using the regToken is effectively
putting a plaintext password into your ir, which means that anyone who
intercepts the message can use it to submit their own request.  It's totally
insecure as an authenticator.

(The original Entrust version of the protocal was designed to run over private
LAN links, so presumably this wasn't seen as a problem for them.  This
assumption did however lead to interesting protocol flaws later on when it was
tested over the Interweb :-).

Incidentally, I'm still not sure why you'd need to use a regToken.  cryptlib
uses a OTP for ir's and employs the value that presumably you're putting in
the regToken as the MAC key.  This works just fine, and protects the exchange
in a way that the regToken doesn't.

Peter.

_______________________________________________
Cryptlib mailing list
Cryptlib@... via Mail: cryptlib-request@...
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.

[Tomas Gustavsson-3]

Thanks for the CMP history Peter. I never liked the CMP spec and now
it's a bit clearer to me :-)

I simply though the regToken would be used in the same way as the
password field usually embedded in PKCS#10 requests
(pkcs_9_at_challengePassword). This is clear text as you say, which is
not perfect in any way. If it is a one time password it's at least
better than nothing...
That was anyhow my interpretation of the thing and how I implemented it
in EJBCA :-)

As I mentioned though, I've not heard of anyone using it this way, but
everyone uses RA mode and HMAC protection.

Cheers,
Tomas


Peter Gutmann wrote:

> Hi,
>
>> I'd be glad if you directed EJBCA specific questions to the EJBCA mailing
>> list or forums. That would avoid misunderstandings about how EJBCA works or
>> not. It's pretty well documented at EJBCA.org, although some clarification
>> can always be done if it's not clear enough.
>
> Oh, sorry, I didn't know this was going to anyone involved with EJBCA, I was
> just responding to a general message on the cryptlib list...
>
>> I usually recommend people looking for a CMP client in C to look at cryptlib,
>> since I have tested it myself that EJBCA and Cryptlib is compatible (you may
>> remember some email a few years back Peter).
>
> Yeah, that's why I was a bit puzzled, I thought maybe EJBCA had changed
> something which had broken things, thus the (somewhat unjustified, sorry)
> "proper implementation" comment.
>
>> 2. If not using "RA mode" an individual user can be authenticated using a
>> one-time password in the CRMF message (not in the CMP message) "Registration
>> token control id-regCtrl-regToken". This is pretty well specified in RFC 4211
>> section 6.1. Is it really an Entrust think?. It seems pretty well specified
>> to me?
>
> Well, you have to know the history of CMP :-).  It was originally an Entrust-
> internal protocol that was proposed as an IETF standard.  After eleven
> rewrites it ended up as CMPv1.  The interop testing for that was that "this
> protocol does not work", so it was kludged into CMPv2 (this is why the RFC
> started with v2 even though there was never officially a v1).
>
> The results of the second attempt at interop testing were so bad that they
> were never published.  After that the authors of the RFCs abandoned them (for
> the 25xx ones) and completely new authors stepped in to do the 42xx versions
> who AFAIK weren't involved in the 25xx fiasco, because there were some edits
> made in 42xx that made things rather more murky than they already were, and
> several of the (non-)interop results that should have gone into any new
> version were never added.
>
> Anyway, one of the artefacts of the CMP origins is that there are lots of
> remnants in there that made sense to Entrust but not to anyone else (the
> original interop notes make interesting reading, I think I quoted some of them
> in the "PnP PKI" paper, things like "What does XYZ do?  Why is it there?  What
> problems does it solve?".  The really scary thing is that there are things in
> there that even the original RFC authors couldn't explain, when asked).
>
> Anyway, regToken is one of the makes-sense-to-Entrust things, I heard from
> another vendor during the first round of (non-)interop tests that Entrust had
> some sort of OTP token that they used with CRMF requests, and regToken was
> used to contain the OTP value.  Since no-one else had any idea what to do with
> this value, no implementation (that I know of) made any use of it.
>
>> Is it not possible to use a regToken in CRMFs with Cryptlib? (I can't recall
>> I did test exactly this).
>
> No, for two reasons, first there's no indication of how this would be used.
> Now admittedly you can say the same for a lot of the rest of CMP but at least
> there was some consensus about what to do with the various fields during the
> interop attempts, with regToken you'd be more or less creating a proprietary
> implementation.
>
> A far more serious problem though is that using the regToken is effectively
> putting a plaintext password into your ir, which means that anyone who
> intercepts the message can use it to submit their own request.  It's totally
> insecure as an authenticator.
>
> (The original Entrust version of the protocal was designed to run over private
> LAN links, so presumably this wasn't seen as a problem for them.  This
> assumption did however lead to interesting protocol flaws later on when it was
> tested over the Interweb :-).
>
> Incidentally, I'm still not sure why you'd need to use a regToken.  cryptlib
> uses a OTP for ir's and employs the value that presumably you're putting in
> the regToken as the MAC key.  This works just fine, and protects the exchange
> in a way that the regToken doesn't.
>
> Peter.

_______________________________________________
Cryptlib mailing list
Cryptlib@... via Mail: cryptlib-request@...
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.