|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Wed, 1 May 91 15:23:04 -0400 From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) To: "John Wray, Secure Systems Development, DTN 226-6106 01-May-1991 Cc: gssapi-dev@ATHENA.MIT.EDU In-Reply-To: John Wray, Secure Systems Development, DTN 226-6106 01-May-1991 1308's message of Wed, 1 May 91 10:50:41 PDT, Reply-To: tytso@ATHENA.MIT.EDU John Wray writes: >Well, the situation I was imagining was that I (the TCP host) had received an >incoming TCP connection from the relay, and so all I know is the internet >address of the relay. I don't know the X.25 address of the originator. I >don't even support X.25! I just want the GSSAPI to tell me who my remote >client is. In this case, passing in the only address available to me (the >relay's internet address) will guarantee failure to authenticate, so I don't >really have any choice but to use GSS_ADDRTYPE_NULL. If we follow your arguments to their logical conclusion you seem to be saying that since the client might be coming from a X.25 address, the server should always pass in GSS_ADDRTYPE_NULL, since otherwise the X.25 client will lose. I don't buy that, since it means that you're requiring that we lose functionality trying to accomodate an uncommon case. I can think of two ways of dealing with this so that "passing in the only address available to you" won't necessarily cause you to lose. The first is that since the X.25 host will need a UDP reply address for the KDC (or CDC, presumably) when it gets the tickets, the IP address of the relay is what will appear in the tickets and passing the only address available to you (the relay's internet address) will Do The Right Thing. The other possibility is that in this case, the X.25 host will request tickets which do not contain address restrictions, and (assuming the KDC will grant zero-address tickets) it won't matter than the server is passing the relay's internet address into accept_context(), since the mechanism won't be checking it. >Choosing not to use addresses therefore isn't a unilateral decision - the >acceptor can't simply refuse to supply them and expect to authenticate >a client that has provided them. If both initiator and verifier decide >that some other form of bindings are more apropriate, or if they need >to use an addresstype that is not known to the mechanism, then they >should still be able to get authentication services from the mechanism. I agree that choosing to use addresses is not a unliateral decision. However, even if the initiator and verifier decided that some other form of bindings (including none at all) are more appropriate, it is questionable whether or not they can do so and ignore whatever security policies the "site security officer" has set up in the mechanism's central KDC or CDC. If the mechanism's requirements are not met, I think a GSS_S_FAILURE is appropriate. (If that is a problem, then the application programmer/application users get to flame to the administrators about the site's security policies :-) - Ted
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |