Re: CMP authentication

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