The MIT KRB5 crypto library supports DES-ECB and DES-CBC, all that your telnet client & server needs to do is to implement the feedback loops around the ecb_encrypt/ecb_decrypt calls to get the *FB modes required by the RFC. The CFB/OFB part of the crypto is pretty easy to implement, its just DES (ECB) with a twist.
Take a look at the telnet encryption code in the MIT source tree: krb5-1.2.2/src/appl/telnet/libtelnet/enc_des.c - specifically, the cfb64_encrypt/decrypt functions. Why are not using the MIT telnet daemon anyway? It already does what you want, I think. -wyllys Ralph Young wrote: > Hi Wyllys, thanks for the feedback. I'm in the process of adding K5 support to > our Telnet server and I'm still a bit confused how to differentiate between the > TELNET encryption types and those used by Kerberos. With K5 Telnet, as I > understand, the authentication options are negotiated and then the encryption > options. > > The problem comes with the encryption negotiation, specifically, the ENCRYPT > SUPPORT & ENCRYPT IS suboptions: > > SB ENCRYPT SUPPORT encryption-type-list... > SB ENCRYPT IS encryption-type... > > If the server says it supports types 1 & 2, per the RFC spec that would refer to > DES_CFB64 & DES_OFB64... how do I get from these types to the encryption types > that Kerberos will use? The Kerberos 5 library will be encrypting the data in a > different format. > > See the confusion? Thanks > > -Ralph > > > > > Wyllys Ingersoll wrote: > > >>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] >>>>> >>>>> >>>>> >>>>>
