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

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

Just curious, is there a way to find the version of Dogtag through the web interface?

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