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]
> 
> 



Reply via email to