|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Mon, 29 Apr 91 13:43:34 PDT From: "John Linn. 508.486.6588. DTN 226-6588. 29-Apr-1991 1643" <linn@zendia.enet.dec.com> To: gssapi-dev@ATHENA.MIT.EDU Ted, > >In attempting to code gss_accept_sec_context, I ran into a problem. > >When Kerberos does a krb5_rd_req(), it requires the sender's network > >address, and there's no place to pass that into gss_accept_sec_context. > > There's some history involved in this issue - John Linn had better take this > one. > >Can we address this soon? Kerberos will not be able to work with the >GSS API unless this problem is resolved, and we were hoping to get a >Beta release of Kerberos V5 out soon that would support the GSS API. If >we do not address this soon, I see three options 1) I code to my >original proposal and have a slightly non-confirming, but functional GSS >API, 2) we drop the GSS API from the beta Kerberos release, or 3) we >push back the beta release of Kerberos. Unfortunately, none of the >three options are particularily desireable. Not all mechanisms require lower-layer addressing information, or tie the authentication function in any way to lower-layer addressing, and requiring every GSSAPI caller to have it available for presentation as an input argument means that any GSSAPI caller resident above the network layer has to be in a position to violate layering (which may be harder in an OSI environment than in the usual IP host). One of the GSSAPI charter goals was independence from addressing representations; this is an elegance argument, sacrificable in the face of clear functional need. I can think of two reasons why Kerberos would want a target-provided IP address; please let me know if there are others. One reason (and the one I'd see us as trying to support by defining a representational convention within channel bindings) is the idea of an independence check between the source address within a Kerberos message and that passed up from the incoming IP layer, essentially drawing on a weak form of host-granularity authentication based on intra-network facilities. I think we should recommend use of a common, extensible form for channel bindings which includes the source address; if no such bindings argument, or another type recognizable as containing other than addresses, were passed in, does this necessarily mean that the strong, cryptographic part of Kerberos authentication can't be performed? Is this really a "Kerberos requires" rather than a "Kerberos would use if provided"? Another use for the IP address would be to provide a value to compare against optional entries in a ticket's caddr field (per KV5 draft 4, p. 24). I believe that such an authorization mechanism (distinguishing a set of addresses from which a ticket may be used, without underlying strong authentication) is Kerberos-specific rather than a feature of a generic service which multiple mechanisms should be assumed to implement; this question came up at the early GSSAPI design meetings (late 1989-early 1990) including Athena participants, and I believe there was agreement to exclude it from the generic service base. --jl
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |