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

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