Telnet Encryption Options vs. Kerberos V5
Ralph Young
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
ralph...@mediaone.net
Wyllys Ingersoll
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
Could a Kerberos V5-Telnet server do authentication only, with no encryption
support for interactive sessions?
-Ralph Young
Wyllys Ingersoll
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
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
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
Jeffrey Altman
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 <3C0CF002...@sun.com>,
Wyllys Ingersoll <wyllys.i...@sun.com> wrote:
:
: The MIT KRB5 crypto library supports DES-ECB and DES-CBC,
: >>>>>
: >>>>>
: >>>>>
: >>>>>
:
--
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
kermit-...@kermit-project.org OpenSSL. SSH soon to follow.
Jeffrey Altman
And of course C-Kermit 8.0 supports Kerberos 5, Kerberos 4, SRP,
SSL/TLS for securing Telnet, FTP, HTTP, RLOGIN, KERMIT, ... See
http://www.kermit-project.org/ck80.html
http://www.kermit-project.org/security80.html
Salil Dangi
news:9umtg9$lej$1...@watsol.cc.columbia.edu...
> 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.)
In order to solve the integrity problem, we have implemented following
variant
where the negotiations are identical to the DES_CBC except for the type:
Encrypted data is sent as follows:
4 byte length of the GSS Wrapped message
GSS Wrapped message.
If the Receiver is expecting encrypted data then it reads 4 bytes, and then
reads bytes specified by the previous 4 bytes and UNWRAPS using
GSS calls.
Salil
Salil Dangi
> news:9umtg9$lej$1...@watsol.cc.columbia.edu...
>
> 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.)
In order to solve the integrity problem, we have implemented following
variant where the negotiations are identical to the DES_CFB64 except
for the type:
Encrypted data is sent as follows:
4 byte length of the GSS Wrapped message
GSS Wrapped message.
If the Receiver is expecting encrypted data then it reads 4 bytes, and
then reads bytes specified by the previous 4 bytes and UNWRAPS
using the GSS calls.
Salil
Jeffrey Altman
Salil Dangi <salil.da...@unisys.com> wrote:
: > "Jeffrey Altman" <jal...@columbia.edu> wrote in message
Just wondering:
. where did you get the Telnet Encryption Option ENCTYPE number from?
Salil Dangi
> . where did you get the Telnet Encryption Option ENCTYPE number from?
RFC 2946 defines available Encryption types.
We have implemented a variant and called it USS_GSS_ENCRYPTION
and currently using a value of 129.
Salil
RFC 2946
ENCRYPT 38
Encryption Commands
IS 0
SUPPORT 1
REPLY 2
START 3
END 4
REQUEST-START 5
REQUEST-END 6
ENC_KEYID 7
DEC_KEYID 8
Encryption Types
Salil Dangi
> and currently using a value of 129.
USS_GSS_ENCRYPTION should read USE_GSS_ENCRYPTION.
Jeffrey Altman
My point is where did you get the value 129, and who authorized
you to use it?
These are internet standards using shared address spaces. You can't
just choose numbers out of a hat. I have already had to deal with
collisions in the name space because people randomly decided to use
arbitrary values without registering them with the appropriate
organizations.
I would be interested in seeing a write-up of your USE_GSS_ENCRYPTION.
I wonder how you are using GSSAPI for ENCRYPTION without using it
for authentication.
In article <9v2rfb$rbk$1...@si05.rsvl.unisys.com>,
Salil Dangi <salil.da...@unisys.com> wrote:
: > Just wondering:
:
:
:
Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 Beta available
Salil Dangi
>authorized you to use it?
This is just a number which we are using for the time being. Our Telnet
Server and Telnet Clients which have implemented this type are configurable
to use any other number for this type. This will allow us to use any IETF
assigned number in future.
> I would be interested in seeing a write-up of your
> USE_GSS_ENCRYPTION.
> I wonder how you are using GSSAPI for ENCRYPTION without
> using it for authentication.
We are using GSSAPI for Kerberos Authentication and Encryption. Our Telnet
server always uses GSSAPI to talk to Kerberos. Our Telnet server is able to
accept either raw AP-Request message (no GSS framing) or with GSS framing.
When the incoming token has GSS framing, the outgoing reply token also has
GSS framing. This allows the MIT style Telnet clients (no GSS framing) to
connect to our Telnet server.
In terms of Telnet negotiations, the negotiations when USE_GSS_ENCRYPTION is
used are identical to the case when the DES_CFB64 is negotiated between the
client and the server. There is no IV associated with the
USE_GSS_ENCRYPTION.
In our case, our Telnet client is runs on the Win2K machine and acquires
service ticket for the remote host using SSPI. This token has GSS framing
and it may also include forwarded credentials. Our Telnet server uses GSSAPI
( who calls Kerberos) to authenticate the client using this token. The
client can use encryption by utilizing SSPI provided EncryptMessage
(GSS_WRAP) calls.
This has allowed the client to work without needing any KRB5 library and we
are able to use either DES or RC4 for encryption.
Salil
"Jeffrey Altman" <jal...@watsun.cc.columbia.edu> wrote in message
news:9v316h$7d7$1...@newsmaster.cc.columbia.edu...
Marcus Watts
> >My point is where did you get the value 129, and who
> >authorized you to use it?
"Salil Dangi" <salil.da...@unisys.com> wrote:
> This is just a number which we are using for the time being. Our Telnet
> Server and Telnet Clients which have implemented this type are configurable
> to use any other number for this type. This will allow us to use any IETF
> assigned number in future.
While I can't answer for sure what Salil was thinking, I see that RFC
2946 makes no provisions whatsoever for "experimental" or "local"
numbers of any sort. All it defines is one byte of address space, and
claims there is plenty of unallocated space left. That doesn't really
leave Salil with much of an alternative to "just picking one". I
presume Salil was looking for a number for "experimental" use, and
wanted to pick a number that was not likely to be confused with
anything else. 129 stored in a signed byte becomes negative, so
perhaps Salil thought of this as being most consistent with K5's
experimental range. Of course, if he intends to use it for wide-spread
production use, it would be a very good thing for him to pursue getting
an "official" number. Writing up a description, and circulating code
would be good too. Salil picked a number that is right where the
defined number allocation scheme presumably changes; I don't know if that was
on purpose or not.
Many standards make provisions for local or experimental usage. The K5
standard specifies negative numbers. When I started putting cast5 into
K5, the first two problems I ran into are:
negative numbers make ugly array indexes,
as K5 1.0 used an array of encryption systems,
-1 was already in use.
I worked out solutions for both of these. My source uses KRB5_WILD
instead of -1 (though I made it -1 in the end anyways). There were
also a bunch of places where MIT tested for KRB5_WILD by saying "< 0",
which I had to fix, in order to make negative types work. It would be
nice to see the MIT k5 source pick up on both these ideas. The array
stuff was, well, ugly. 1.1+ handles this much better. I think
there may have also been something ugly about ASN.1 basic encoding
rules, but it's been long enough that I've forgotten. All in all,
using negative numbers with MIT k5 was unexpected annoying.
I don't remember GSSAPI making any provisions for experimental numbers.
I ended up picking 0x0072, 0x0073, and 0x0063 for my sgn_alg and
seal_alg types, because these seemed least likely to break what
was already obviously very fragile code. Of course, I regard these as
"disposable" numbers -- I have no interest in deploying any
production use of cast5 or rc6 today.
-Marcus Watts
UM ITCS Umich Systems Group
Salil Dangi
assumption, the value is 129 and not negative 1.
The reason for selecting 129 was to just avoid any known conflict with any
currently assigned or soon to be assigned value. The default configuration
files supplied with our Telnet server and clients have a statement which
defines this type and can be altered to use any number in the 0-255 range.
(USE_GSS_ENCRYPTION = 129)
Short description of our implementation is as follows:
- Encryption negotiation are just like the RFC2947.
- It requires that Authentication using KRB V5 has successfully completed, a
GSS context is established and a shared session key is available.
- Encryption type is USE_GSS_ENCRYPTION
- There are no Suboption Commands.
- There is no IV needed.
- IS response is as follows:
IAC SB ENCRYPT IS USE_GSS_ENCRYPTION IAC SE
- REPLY response is as follows (there is no IV _OK or _BAD):
IAC SB ENCRYPT REPLY USE_GSS_ENCRYPTION IAC SE IAC
- KeyID of 0 implies the default key which is the session key negotiated
during authentication.
- Algorithm for Encryption
Use GSS_WRAP to encrypt
- Encrypted data on the wire
4 bytes containing length of the GSS_WRAP message followed by the token
from GSS_WRAP call (e.g. 00 00 00 35 to represent 53 bytes of GSS_WRAP
token, followed by GSS_WRAP token 60 33 06 09 .....)
- Receiver of encrypted data will kill the connection if the length is not
meaningful. In our case if it is greater than 64K)
- Receiver of encrypted data will kill the connection if the GSS_WRAP token
can not be decrypted without error using GSS_UNWRAP call.
Salil
"Marcus Watts" <m...@umich.edu> wrote in message
news:2001121100...@quince.ifs.umich.edu...
Marcus Watts
> We are treating this field to be an unsigned integer of one byte. With this
> assumption, the value is 129 and not negative 1.
Nit pick: 129 or 0x81 would actually be -127. 255 or 0xff would be -1.
those who know me have no need of my name
>"Salil Dangi" <salil.da...@unisys.com> writes:
>> We are treating this field to be an unsigned integer of one byte. With this
>> assumption, the value is 129 and not negative 1.
>
>Nit pick: 129 or 0x81 would actually be -127. 255 or 0xff would be -1.
given certain, other, assumptions.
--
okay, have a sig then
Jeffrey Altman
with what has been done. However, if this code has been shipped it is
sure to cause difficulties.
As one of the authors of the Telnet Auth and Encrypto Options I would
have appreciated being contacted about the subject because there has been
quite a bit of discussion of how this should be implemented.
In particular, it is expected that a GSSAPI-Kerberos-5 implementation
would not use the Telnet ENCRYPT Option as all. Instead it should as
per RFC 2941 use the ENCRYPT_AFTER_EXCHANGE option. No additional
information is exchanged as part of the ENCRYPT negotiation therefore
there is no point in implementing it. Especially since it is considered
to be headed for Historical status real soon now.
Since you are serious about implementing this option I would like to see
it be allocated an official AUTH TYPE value and be published as
an internet draft. A year ago there was a Telnet Security BOF in which
a vote was taken to form a new Telnet Security working group. The group
was never formed because I was unable to find someone to chair or edit
the IDs. The same person cannot do both.
Please contact me directly at jal...@columbia.edu.
In article <9v3evs$1c27$1...@si05.rsvl.unisys.com>,
Salil Dangi <salil.da...@unisys.com> wrote:
: >My point is where did you get the value 129, and who
: