onsdag den 15 augusti 2012 klockan 13:07 skrev Simon Josefsson detta: > Mats Erik Andersson <[email protected]> writes: > > > torsdag den 9 augusti 2012 klockan 19:40 skrev Simon Josefsson detta: > >> Mats Erik Andersson <[email protected]> writes: > >> > >> However, if you have more than one ticket in your ticket cache, I'm not > >> sure there is a way to ask the client which ticket to use. MIT/Heimdal > >> doesn't have this problem, I believe, since they don't support storing > >> tickets for multiple user principals in their ticket files. We would > >> need another switch for this, say: > >> > >> telnet --realm EX.ORG --remote-principal telnet/kdc.ex.org > >> --use-ticket sigge/[email protected] kdc.ex.org > >> > >> where --realm and --remote-principal specify the Kerberos name of the > >> remote server and --use-ticket specify which local ticket it should > >> authenticate with. > > > > This needs serious thinking. > > > > The recent interop server leads to a further line of refinement: > > > > * Is it difficult to implement in telnetd a compatibility > > layer of encryption in order that a MIT Kerberos or > > Heimtal telnet client be made able to use encrypted > > communication with our libshishi based telnet server? > > Doesn't that work automatically? The selection complexity is only on > the client side. MIT/Heimdal doesn't have the complexity, because only > one principal identity is supported. Shishi have the complexity, but > there is no complexity on the server side. The complexity is in the > client side (i.e., telnet) when selecting which ticket to use. We can > punt on this, and just use the "default" Shishi ticket. I think that > would be an acceptable solution.
You read too quickly. The matter is interoperable encryption, not naming of user principals. As you stated yourself on [email protected], and as I could verify, an MIT client is not able to contact your TELNET server at "interop.josefsson.org". The authentication works correctly, but the actual payload exchange fails, which I interpreted as being due to encryption. Am I mistaken? Regards, Mats
