Re: [bug-inetutils] Present libshishi support.

[Mats Erik Andersson]

onsdag den 15 augusti 2012 klockan 13:07 skrev Simon Josefsson detta:
> Mats Erik Andersson <address@hidden> writes:
> 
> > torsdag den  9 augusti 2012 klockan 19:40 skrev Simon Josefsson detta:
> >> Mats Erik Andersson <address@hidden> 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/address@hidden 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 address@hidden, 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