|
« Return to Thread: CMP authentication
Re: CMP authentication
by Peter Gutmann
::
Rate this Message:
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.
>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.
« Return to Thread: CMP authentication
| Free embeddable forum powered by Nabble | Forum Help |
