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

[Fraser Tweedale]

On Wed, Dec 10, 2014 at 02:30:40PM +1000, Fraser Tweedale wrote:
> 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.
> 
Fedora 21 has just been released, and Fedora 19 will reach End Of
Life in a month, and we will not be backporting the patch.  We
recommend upgrading to Fedora 21 via the fedup tool
(https://fedoraproject.org/wiki/FedUp).

HTH

Fraser

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