No problem. I think the telnet client defaults to NOT use encryption. The "-a" option should force it to try automatic authentication with KRB5. "-x" will have the client attempt to negotiate the encryption per RFC 2946. See the man page.
-Wyllys Ralph Young wrote: > Bear with me, still somewhat a newbie to Kerberos... > > Could a Kerberos V5-Telnet server do authentication only, with no encryption > support for interactive sessions? > > -Ralph Young > > Wyllys Ingersoll wrote: > > >>The data encryption types negotiated as described by RFC 2946 are >>completely separate from the Kerberos encryption types that >>Kerberos uses to create keys, etc. You may have a KDC that only >>supports DES-CBC types but a telnet client (and server) that >>support completely different encryption types for the actual >>telnet session. >> >>In fact, a telnet client and server may support RFC-2946 but >>not necessarily support Kerberos. Though I've never seen >>such a situation, the RFC does not require the use of Kerberos >>for keys or authentication. >> >>The MIT telnet client and server may only support the DES_CBC types, >>the rest is an exercise left up to the reader :) >> >>-wyllys >> >>Ralph Young wrote: >> >> >>>The Telnet Data Encryption Option - as defined by RFC 2946 - shows the >>>following encryption types: >>> >>>NULL 0 >>>DES_CFB64 1 >>>DES_OFB64 2 >>>DES3_CFB64 3 >>>DES3_OFB64 4 >>>CAST5_40_CFB64 8 >>>CAST5_40_OFB64 9 >>>CAST128_CFB64 10 >>>CAST128_OFB64 11 >>> >>>Kerberos V5, however, appears to support just the DES_CBC encryption >>>types... it appears to me a telnet client may request one of the above >>>encryption types, not a K5 encryption type. >>> >>>Therefore, my question: for a Kerberos 5 Telnet Server application, how >>>would the Kerberos encryption types be negotiated? >>> >>>TIA, >>> >>>Ralph Young >>>[EMAIL PROTECTED] >>> >>> >>>
