|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Wed, 1 May 91 11:27:14 -0400 From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) To: "John Wray, Secure Systems Development, DTN 226-6106 30-Apr-1991 Cc: gssapi-dev@ATHENA.MIT.EDU In-Reply-To: John Wray, Secure Systems Development, DTN 226-6106 30-Apr-1991 1450's message of Tue, 30 Apr 91 13:05:16 PDT, Reply-To: tytso@ATHENA.MIT.EDU John, you've brought out a lot of interesting and thought-provoking points. However, I don't know if I agree with your conclusion: >From above, this isn't just an OSI vs TCP/IP problem. I have no problems with >the above, except, for the reasons above, the GSS_ADDRTYPE_NULL should always >be allowed, with the explicit proviso that if it's specified, then the >application is explicitly opting out of providing the adddress, and source >network-address checks by the mechanism will therefore be impossible. By not >providing a source address, the application is saying that it doesn't care. It would seem that the mechanism should be making the security decision of whether or not the source (or receiver) address matters, _not_ the application. Insofar as the low-level transport address provides some level of protection against attacks, this is an authentication decision which the mechanism may want to make based on this information; it is not necessarily an authorization decision. I could imagine authentication systems where the hostname might be part of the authenticated principal, and as such the decision to allow a user operating at one (trusted) hosts versus allowing a user operating at another host would be an authorization decision made by application. However, the source (and receiver) addresses can also be used to make authentication decisions, by on comparing the source address against information sealed inside a ticket to make exploting stolen tickets more difficult. Why should we prevent that? As for the two examples which John presented, the X.25 to TCP/IP relay and the PC w/o a network address, let's look at them in reverse order. If the PC really doesn't have a network address then the server can use GSS_ADDRTYPE_NULL without any problems. I note in passing that neither Kerberos nor SPX will be able to run w/o modification, since both mechanisms assume that the client can contact the KDC or the CDC, and it's a bit difficult to do this without a network address. But if the PC really is in an environment where network address don't exist or where it is impossible to obtain them, GSS_ADDRTYPE_NULL would be appropriate. As for the X.25 to TCP/IP relay, even if the X.25 source address cannot be trusted (because you don't trust the relay to give you authoratative information about where the X.25 connection _really_ came from), is that an excuse not to put the (admittedly possibly suspect) information into the sender_address field, instead of GSS_ADDRTYPE_NULL? Presumably the person who modified the mechanism to accept X.25 source address in addition to TCP/IP address knew that X.25 source address might not be secure since they need to go through a relay, so it should be his responsibility to use or not use the information as appropriate. I feel strongly that the application should not ever withhold information to the mechanism --- let the mechanism decide what do to with the information, since it can always ignore it. - Ted
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |