[Pki-users] Best way to bypass challenge password verification

Wed Dec 10 04:30:40 UTC 2014

On Fri, Dec 05, 2014 at 09:22:34AM -0500, Peter Beal wrote:
> 
> On 12/4/14 7:08 PM, Fraser Tweedale wrote:
> >On Thu, Dec 04, 2014 at 10:36:10AM -0500, Peter Beal wrote:
> >>Hi Fraser,
> >>
> >>Thanks for the quick response.
> >>
> >>I saw the ticket get opened.  Thanks for jumping on that as well.
> >>
> >>What I see at our EST based client as it is building the CSR is the
> >>following value being used for the challenge password
> >>
> >>(gdb) p tls_uid
> >>$35 = 0x7ffff001a4d0 "H9wOU8vX9HX5s/hH"
> >>(gdb)
> >>
> >>We take the TLS UID and run it through a base64 encoding and the above
> >>string is what is placed in the challenge password field. This appears to be
> >>a printable string for us as it's placed into the CSR.  We verify the CSR at
> >>the EST server and then send it on to Dogtag unmodified.  I haven't go into
> >>the RA or Dogtag to verify this, but I suspect this string is still set to
> >>this value when it arrives at Dogtag.
> >>
> >>Thanks again for you help,
> >>Pete
> >>
> >The DER data in the Dogtag log output shows that the
> >challengePassword attribute value has UTF8String encoding (tag
> >0x0C), not PrintableString (tag 0x13).  Dogtag MUST be able to parse
> >UTF8String challengePassword attributes, but according to the RFCs
> >the value SHOULD have PrintableString encoding, so you may want to
> >look into it.
> >
> >I have a patch for the decoding issue in the works; should get it to
> >the pki-devel list for review this morning.  What OS and Dogtag
> >version are you running?  Hopefully we can get that patch in the
> >next Dogtag release for your distro.
> >
> >Regards,
> >
> >Fraser
> Fedora version is 19 and the Dogtag version appears to be
> 
> Implementation-Version: 10.0.6
> 
I am not sure if the patch will be backported to f19.  Stay tuned.

> Just curious, is there a way to find the version of Dogtag through the web
> interface?
> 
I am not aware of a way.

Regards,

Fraser

> Thanks,
> Pete
> >>On 12/3/14 10:44 PM, Fraser Tweedale wrote:
> >>>On Wed, Dec 03, 2014 at 02:16:47PM -0500, Peter Beal wrote:
> >>>>Hello,
> >>>>
> >>>>Our group is developing its own RA to be part of a PKI solution that
> >>>>includes Dogtag.  Our solution uses EST (RFC 7030) between the the clients
> >>>>and the RA, with the EST protocol terminating at the RA. The RA then takes
> >>>>the CSRs and sends them on to Dogtag using REST commands.  This project has
> >>>>been going very well, however we did just hit one issue that we were hoping
> >>>>others might be able to provide some guidance on.
> >>>>
> >>>>The EST protocol defines a feature called Proof Of Possession (PoP) where
> >>>>the clients insert the TLS unique ID of the TLS session between it and the
> >>>>EST server, in our case our RA. This TLS UID is sent in the challenge
> >>>>password attribute field of the CSR so that it can be signed by the client.
> >>>>The EST server is responsible for verifying this TLS UID, and once this
> >>>>verification is performed the value in the challenge password field no
> >>>>longer has any meaning. Because the CSR cannot be resigned at this point,
> >>>>the challenge password cannot be taken out of the CSR.  This CSR is passed
> >>>>as is along to Dogtag and we're currently finding that Dogtag is checking
> >>>>the CSR and does not like the challenge password attribute:
> >>>>
> >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: Start parsePKCS10():
> >>>>MIIBdDCB3gIBADAUMRIwEAYDVQQDDAkxMjcuMC4wLjEwgZ8wDQYJKoZIhvcNAQEB
> >>>>BQADgY0AMIGJAoGBAMPNKtwZO82WfR5u/hS+SsVghdS9jD5BQS6Z5ymXrKcr9R4t
> >>>>DtSeEQ+AtCZ5qVNXcangb00vJgVqgS/7NH4MzSqscgNzZdpx9+mPklvOUuqTuYCv
> >>>>MFIlMwP/2DJ6TBrmF86vJ1I0GmZAyTSzHg4V4YWaN7r0V7x0RyvFqoBnZU51AgMB
> >>>>AAGgITAfBgkqhkiG9w0BCQcxEgwQTUR4clVZNmd6TnZqdWRmNzANBgkqhkiG9w0B
> >>>>AQsFAAOBgQAAKLbWGndYFfa+8IhopufYOEKIOAmcT+Nhr27vFt5I4ymoUwSlKX9L
> >>>>K+KpLho5Q2GsRoItNXJ6VxRcGe1CPZBW2ef7yPdZaKhFmnxXsYVQaqPY5BGI8kAY
> >>>>MMMr75WQcpn+XUpu+FNB4F2j8YY314u2rsplCMbOdR4tcrgc8WqucA==
> >>>>
> >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10:
> >>>>signature verification enabled
> >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10:
> >>>>use internal token
> >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10
> >>>>setting thread token
> >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10
> >>>>java.io.IOException: DerValue.getPrintableString, not a string 12
> >>>>[03/Dec/2014:13:37:59][http-bio-8444-exec-3]: EnrollProfile: parsePKCS10
> >>>>restoring thread token
> >>>>
> >>>>So we're wondering what the best approach might be to handle this. Is there
> >>>>a way to configure Dogtag so that it will ignore the challenge password?
> >>>>
> >>>>Thanks very much,
> >>>>Pete Beal
> >>>>
> >>>Hi Pete,
> >>>
> >>>Dogtag tries to decode the request object as a whole (and is
> >>>failing; see below).  There is no way to bypass this.
> >>>
> >>>PKCS #9 (RFC 2985) §5.4.1 "Challenge password" states that "PKCS #9-
> >>>attribute processing systems MUST be able to recognize and process
> >>>all string types in DirectoryString values."  Therefore, this is a
> >>>bug in Dogtag, and I will file a ticket.  (Incidentally, OpenSSL
> >>>also fails to deal with with this part of the request object, but
> >>>the problem is isolated to the attribute.)
> >>>
> >>>The problem should not present when using PrintableString instead of
> >>>UTF8String.  Since according to RFC 7030 (EST) the value of the
> >>>challengePassword attribute is base64 encoded, it is printable, and
> >>>furthermore RFC 2985 also states, "ChallengePassword attribute
> >>>values generated in accordance with this version of this document
> >>>SHOULD use the PrintableString encoding whenever possible."  If you
> >>>have control over the clients (I understand you may not) then using
> >>>PrintableString instead of UTF8String is recommended and should get
> >>>you over the line with Dogtag until the decoding issue is fixed on
> >>>our end.
> >>>
> >>>Cheers,
> >>>
> >>>Fraser
>