We are treating this field to be an unsigned integer of one byte. With this 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" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > 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 >
