As long as this code is not being shipped to customers I have problem 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 [EMAIL PROTECTED] In article <9v3evs$1c27$[EMAIL PROTECTED]>, Salil Dangi <[EMAIL PROTECTED]> wrote: : >My point is where did you get the value 129, and who : >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" <[EMAIL PROTECTED]> wrote in message : 9v316h$7d7$[EMAIL PROTECTED]">news:9v316h$7d7$[EMAIL PROTECTED]... : > I know the text of RFC 2946 very well. I am one of the authors. : > : > 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$[EMAIL PROTECTED]>, : > Salil Dangi <[EMAIL PROTECTED]> wrote: : > : > Just wondering: : > : > . where did you get the Telnet Encryption Option ENCTYPE number from? : > : > Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 Beta : available : > : : > : 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 : > : 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 : > : : > : : > : : > : > : > 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. : : 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.
