The issue I described below turned out to be misinterpretation of the MS-CSSP
spec. The TSCredential is defined as follows:
TSCredentials ::= SEQUENCE {
credType [0] INTEGER,
credentials [1] OCTET STRING
}
I somehow wrote the encoding code treating TSCredentials.credentials as a
choice object of either TSPasswordCreds or TSSmartCardCreds. This encoding
caused a decode error on the server side which presented itself as a TLS Alert
80. Changing my code to encode the TSSmartCardCreds as an octet string has
corrected this problem. Many thanks to Tarun Chopra for his assistance in
capturing the credentials structure from the server side; which highlighted
this error.
I am no looking into why the session does not logon to the desktop with the
provided credentials. So far it appears as though that MSTSC might be pushing
the SC Cert onto the server and storing it in a cert store so that the logon
will work. If anyone has any insight on this part, I welcome your input!
Thanks,
Nik Twerdochlib
From: Nik Twerdochlib
Sent: Monday, September 30, 2013 6:19 PM
To: freerdp-devel@lists.sourceforge.net
Cc: Nik Twerdochlib
Subject: Adding logon smartcard authentication support
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=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
