I have been working on adding support for performing authentication using a smartcard certificate. So far I have the authentication piece working using Kerberos, but have run into an issue with the last TS_REQUEST message. The authInfo data that I am building, consisting up TS_SMARCCARD_CREDS and TS_CSPDATADETAIL data gets encrypted and the TS_REQUEST is sent to the server. The server is responding with a TLS 80 Fatal Error and dropping the connection. I have not been able to determine why this is happening so I am wondering if anyone could provide any input?
The TS_SMARTCARD_CREDS structure includes a keyspec value of 1 and the TS_CSPDATADETAIL structure. I am not sending any data for the optional Hints fields. The TS_CSPDATADETAIL structure includes data for the cardName, readerName, containerName and cspName fields. These strings are Unicode. Looking at a dump of the ber data, before encryption seems to show that the asn.1 structure is correct. Sample of the TS_Credentials sequence is below: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 30 82 01 7E A0 03 02 01 02 A1 82 01 75 30 82 01 0'.~ ....¡'.u0'. 00000010 71 A0 0A 04 08 31 00 32 00 33 00 34 00 A1 82 01 q ...1.2.3.4.¡'. 00000020 61 30 82 01 5D A0 03 02 01 01 A1 1A 04 18 43 00 a0'.] ....¡...C. 00000030 53 00 53 00 49 00 20 00 4B 00 6F 00 6E 00 61 00 S.S.I. .K.o.n.a. 00000040 20 00 32 00 36 00 A2 6A 04 68 53 00 43 00 4D 00 .2.6.¢j.hS.C.M. 00000050 20 00 4D 00 69 00 63 00 72 00 6F 00 73 00 79 00 .M.i.c.r.o.s.y. 00000060 73 00 74 00 65 00 6D 00 73 00 20 00 49 00 6E 00 s.t.e.m.s. .I.n. 00000070 63 00 2E 00 20 00 53 00 43 00 52 00 33 00 33 00 c... .S.C.R.3.3. 00000080 78 00 20 00 55 00 53 00 42 00 20 00 53 00 6D 00 x. .U.S.B. .S.m. 00000090 61 00 72 00 74 00 20 00 43 00 61 00 72 00 64 00 a.r.t. .C.a.r.d. 000000A0 20 00 52 00 65 00 61 00 64 00 65 00 72 00 20 00 .R.e.a.d.e.r. . 000000B0 30 00 A3 76 04 74 6C 00 65 00 2D 00 53 00 6D 00 0.£v.tl.e.-.S.m. 000000C0 61 00 72 00 74 00 63 00 61 00 72 00 64 00 4C 00 a.r.t.c.a.r.d.L. 000000D0 6F 00 67 00 6F 00 6E 00 32 00 30 00 34 00 38 00 o.g.o.n.2.0.4.8. 000000E0 2D 00 61 00 65 00 33 00 37 00 32 00 31 00 35 00 -.a.e.3.7.2.1.5. 000000F0 65 00 2D 00 62 00 64 00 36 00 38 00 2D 00 34 00 e.-.b.d.6.8.-.4. 00000100 36 00 31 00 36 00 2D 00 62 00 66 00 33 00 64 00 6.1.6.-.b.f.3.d. 00000110 2D 00 64 00 61 00 61 00 31 00 36 00 62 00 34 00 -.d.a.a.1.6.b.4. 00000120 31 00 63 00 38 00 37 00 39 00 A4 56 04 54 43 00 1.c.8.7.9.¤V.TC. 00000130 68 00 61 00 72 00 69 00 73 00 6D 00 61 00 74 00 h.a.r.i.s.m.a.t. 00000140 68 00 69 00 63 00 73 00 20 00 53 00 6D 00 61 00 h.i.c.s. .S.m.a. 00000150 72 00 74 00 20 00 53 00 65 00 63 00 75 00 72 00 r.t. .S.e.c.u.r. 00000160 69 00 74 00 79 00 20 00 49 00 6E 00 74 00 65 00 i.t.y. .I.n.t.e. 00000170 72 00 66 00 61 00 63 00 65 00 20 00 43 00 53 00 r.f.a.c.e. .C.S. 00000180 50 00 P. I do not receive errors on the EncryptMessage() call. The buffer for the token is set to cbSecurityTrailer, and the resulting authInfo buffer is constructed using the resulting token size and the encrypted data. I have even tried prepending the length of the encypted data in authInfo and still got the same error. In comparison of this message to the same message captured using MSTSC using SC authentication shows that my message is +24 bytes. It seems like that number should stick out enough to be noticed but after tearing my message a part over and over I cannot find any data that adds up to 24 bytes. Since I cannot decrypt the authInfo data from the MTSC network capture I cannot compare byte for byte. So I am hoping there are a few RDP Gurus on this list that might be willing to shed some light on what the RDP server is validating on this TS_REQUEST message that would cause it to through an alert. Thanks, Nik ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
