In a very brief summary. The Kerberos crypto system used to protect the session key and the service information is only loosely connected to the encryption types negotiated by the telnet client and server. When Kerberos is used as the authentication method, the session key is generated as a direct side effect of the authentication process. Therefore, the size of the session key is dependent upon the types supported by the underlying Kerberos implementation. It is because of the fact that Kerberos was traditionally DES only that the Kerberos Telnet implementations only support the DES encryption types.
When SRP is used as the authentication protocol it produces 40 bytes of key data. This is enough data to create six separate keys for use by 3DES (three keys for each direction) without any key being reused. Or enough key data for two CAST-128 keys. However, the Telnet Encryption option regardless of the key strength does not provide integrity protection and so it should no longer be used. Instead, STARTTLS should be used to negotiate a TLS cipher to protect the session and run Telnet over that with an optional Kerberos 5 authentication to verify the TLS session. (Kerberos 5 could also be used as the key exchange method in the TLS negotiation.) The SRP distribution includes a Telnet client and server which implement the STARTTLS option with Kerberos 5 authentication. It builds against the MIT Krb5 1.2.x distribution. I recommend that all users use that server instead of the one that is shipped with MIT. The reason MIT does not support STARTTLS at this point is that it requires the use of OpenSSL and they do not distribute OpenSSL as part of their distribution. In article <[EMAIL PROTECTED]>, Wyllys Ingersoll <[EMAIL PROTECTED]> wrote: : : 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] : >>>>> : >>>>> : >>>>> : >>>>> : -- Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 Beta available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. SSH soon to follow.
