|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Wed, 1 May 91 18:21:35 -0400 From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) To: Charlie Kaufman <kaufman@kibitz.enet.dec.com> Cc: gssapi-dev@ATHENA.MIT.EDU In-Reply-To: Charlie Kaufman's message of Wed, 1 May 91 12:45:42 PDT, Reply-To: tytso@ATHENA.MIT.EDU Date: Wed, 1 May 91 12:45:42 PDT From: Charlie Kaufman <kaufman@kibitz.enet.dec.com> Maybe it's my imagination, but it seems like we have indeed reached a compromise on how to fix the channel bindings problem and now all we are doing is speculating about possible future problems. Yes, we have. Thank you for bringing us back to reality. 1) Will Kerberos support the case where sender_addrtype is missing? Supporting this case is an unnatural thing for Kerberos to be able to do, but it could be managed by including the network address of the sender in the token. If we did that, the application would not get the network address protection that normal Kerberos applications do. I believe for the first implementation, the we should do the easiest thing which is not to support this case. We can discuss adding this "feature" to the Kerberos GSSAPI if it is ever the most important question on our agenda. I think the answer to "should Kerberos support the case where sender_addrtype is missing" should be: No. The ramficiations of this decision, however, is that in environments where the sender address is available, it is mandatory that the application pass it to gss_accept_security_context(). (Otherwise, we lose interoperability.) If this doesn't bother people, I think we have our compromise. I hate to muddy the waters when it seems like we have a solution, but there are some ways in which I would have done this differently: 1) Given that Kerberos doesn't need the receiver address type for anything, I would have left that out and had applications include it in application specific data if they felt it appropriate. My understanding is that SPX needed it. If the people implementing SPX say they don't need the receiver address, it could go away. It does seem to make things symmetric and aethestically pleasing to have both sender and receiver, but those aren't good reasons when specifing an interface. :-) 2) I don't remember what the difference is between a gss_buffer_desc and a gss_buffer_t, but it would be nice if we passed in the same kind of thing for addresses and application data. I would have preferred a count and a pointer to byte, but maybe that's what one of those is. gss_buffer_t is a pointer to gss_buffer_desc. The reason why I made application data be gss_buffer_t is since it's optional, you would want to put in GSS_C_NO_BUFFER in. We could say that the way to omit the application data is to set the length field of the application data to zero. This would avoid having an extra nested strcuture that we would need to allocate and free. So are we agreed on a compromise? The one change which I would recommend at this point would be to change the type on the application data to be gss_buffer_desc, so that sender_address, receiver_address, and appl_specific are all the same type. But other than that, have we reached consensus on this issue? Dare I hope.... - Ted
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |