Skip Menu |
 

Download (untitled) / with headers
text/plain 17.2KiB
From donn@u.washington.edu Mon Dec 3 16:24:24 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id QAA08961
for <bugs@RT-11.mit.edu>; Mon, 3 Dec 2001 16:24:24 -0500 (EST)
Received: from melville.u.washington.edu (melville.u.washington.edu [128.95.135.35])
by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA21635
for <krb5-bugs@mit.edu>; Mon, 3 Dec 2001 16:24:23 -0500 (EST)
Received: (from donn@localhost)
by melville.u.washington.edu (8.11.6+UW01.08/8.11.6+UW01.10) id fB3LOL448698;
Mon, 3 Dec 2001 13:24:21 -0800
Message-Id: <200112032124.fB3LOL448698@melville.u.washington.edu>
Date: Mon, 3 Dec 2001 13:24:21 -0800
From: donn@u.washington.edu
Reply-To: donn@u.washington.edu
To: krb5-bugs@mit.edu
Subject: multiple IP addresses vs. GSSAPI
X-Send-Pr-Version: 3.99

Show quoted text
>Number: 1022
>Category: krb5-libs
>Synopsis: accept_sec_context() specifies principal to rd_req()
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Mon Dec 3 16:25:01 EST 2001
>Last-Modified: Mon Apr 08 17:52:00 EDT 2002
>Originator: Donn Cave
>Organization:
University Computing Services
University of Washington
Show quoted text
>Release: krb5-1.2.2
>Environment:
Any
System: AIX melville 3 4 00600210C000


Show quoted text
>Description:
ftpd and other Kerberos services implemented with GSSAPI are
unable to authenticate on alternate IP+DNS addresses supported
by separate network interfaces. For example back door networks.
The MIT telnetd avoids this problem by passing a null pointer
to krb5_rd_req's 4th parameter. GSSAPI krb5_gss_accept_sec_context()
should do likewise.
Show quoted text
>How-To-Repeat:
Set up a host with 2 interfaces, DNS host_a and IP ip_a on one
and host_b and ip_b on the other, and populate the keytab with
ftp & host keys for both host_a & host_b. Connect with ftp.
Result will be "wrong principal", from krb5_rd_req()
Show quoted text
>Fix:
*** lib/gssapi/krb5/accept_sec_context.c.dist Tue Nov 6 15:25:51 2001
--- lib/gssapi/krb5/accept_sec_context.c Mon Dec 3 13:08:40 2001
***************
*** 345,351 ****
goto fail;
}

! if ((code = krb5_rd_req(context, &auth_context, &ap_req, cred->princ,
cred->keytab, NULL, &ticket))) {
major_status = GSS_S_FAILURE;
goto fail;
--- 345,351 ----
goto fail;
}

! if ((code = krb5_rd_req(context, &auth_context, &ap_req, NULL,
cred->keytab, NULL, &ticket))) {
major_status = GSS_S_FAILURE;
goto fail;
Show quoted text
>Audit-Trail:

From: Donn Cave <donn@u.washington.edu>
To: krb5-bugs@mit.edu
Cc: Subject: Re: krb5-libs/1022: multiple IP addresses vs. GSSAPI
Date: Tue, 4 Dec 2001 12:25:04 -0800

Quoth krb5-bugs@mit.edu:
| Thank you very much for your problem report.
| It has the internal identification `krb5-libs/1022'.
| The individual assigned to look at your
| report is: krb5-unassigned.
|
| >Category: krb5-libs
| >Responsible: krb5-unassigned
| >Synopsis: accept_sec_context() specifies principal to rd_req()
| >Arrival-Date: Mon Dec 3 16:25:01 EST 2001

Minutes after posting this bug report, it was brought to my attention that

1. This approach defers responsibility for validating the service part
of the principal to the service. As telnetd verifies that the actual
principal starts with "host/" and not "imap/" or whatever, so would
ftpd have to check for "ftp/". To the extent that it matters.

2. The problem with multiple IP addresses can also be resolved in
ftpd.c, replacing gethostbyname(localhost) with gethostbyaddr(ctrl_addr).

I still propose to modify accept_sec_context.c as described, because
it is more flexible and because it seems like there's a slim chance it
might be considered. I will also post one per #2 against ftpd, but
after years of submitting a similar bug against ftp I don't expect much.

Thanks,
Donn Cave, University Computing Services, University of Washington
donn@u.washington.edu

From: Sam Hartman <hartmans@MIT.EDU>
To: donn@u.washington.edu
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-libs/1022: accept_sec_context() specifies principal to rd_req()
Date: Mon, 8 Apr 2002 13:47:25 -0400 (EDT)

This patch seems wrong because it ignores a principal name that was
supplied. It seems that allowing gss_accept_sec_context to work with
a default credential (as gss_init_sec_context does), or to allow
gss_acquire_creds to take a default name would be preferable to your proposed solution.

I'd be interested in a patch to this problem, but I don't feel
comfortable with a patch that throws away information from the
application when it is supplied. Just as krb5_rd_req has a fourth
argument, GSSAPI should respect the service name when provided.



From: "Donn Cave" <donn@u.washington.edu>
To: Sam Hartman <hartmans@MIT.EDU>
Cc: <krb5-bugs@MIT.EDU>, <krbdev@MIT.EDU>
Subject: Re: krb5-libs/1022: accept_sec_context() specifies principal to rd_req()
Date: Mon, 8 Apr 2002 12:03:28 -0700

Quoth Sam Hartman <hartmans@MIT.EDU>:

| This patch seems wrong because it ignores a principal name that was
| supplied. It seems that allowing gss_accept_sec_context to work with
| a default credential (as gss_init_sec_context does), or to allow
| gss_acquire_creds to take a default name would be preferable to your proposed solution.
|
| I'd be interested in a patch to this problem, but I don't feel
| comfortable with a patch that throws away information from the
| application when it is supplied. Just as krb5_rd_req has a fourth
| argument, GSSAPI should respect the service name when provided.

It turns out that we were able to solve our particular problem at our
site more easily in ftpd itself, by resolving the DNS name more accurately
as I suggested in the very next bug, krb5-appl/1023. If that could be done,
then I'd have no stake in this issue. In any case it isn't as important
as the GSS_C_NO_CHANNEL_BINDING support that Jeffrey Altman submitted some
time back for this file.

In principle, though, I don't see this as throwing away information.
The information in question is "who did I authenticate as", and that
is available in the context via gss_inquire_context(). (I think,
haven't verified that.) The problem is that currently, krb5_rd_req()
goes on to turn this information into policy, at a level that's not
accessible to the application. Like telnetd (which I believe checks
principal name minus instance), ftpd could enforce its own policy in
this matter, but it has to get past gss_accept_sec_context() first.

Donn Cave, University Computing Services, University of Washington
donn@u.washington.edu

From: Sam Hartman <hartmans@MIT.EDU>
To: "Donn Cave" <donn@u.washington.edu>
Cc: <krb5-bugs@MIT.EDU>, <krbdev@MIT.EDU>
Subject: Re: krb5-libs/1022: accept_sec_context() specifies principal to rd_req()
Date: 08 Apr 2002 15:12:10 -0400

Show quoted text
>>>>> "Donn" == Donn Cave <donn@u.washington.edu> writes:

Show quoted text
Donn> Quoth Sam Hartman <hartmans@MIT.EDU>: | This patch seems
Donn> In principle, though, I don't see this as throwing away
Donn> information. The information in question is "who did I
Donn> authenticate as", and that is available in the context via
Donn> gss_inquire_context(). (I think, haven't verified that.)
Donn> The problem is that currently, krb5_rd_req() goes on to turn
Donn> this information into policy, at a level that's not
Donn> accessible to the application. Like telnetd (which I
Donn> believe checks principal name minus instance), ftpd could
Donn> enforce its own policy in this matter, but it has to get
Donn> past gss_accept_sec_context() first.

OK, but applying this patch would create a security problem for
applications that do not check the service authenticated to and that
have access to keys at multiple trust levels.

More over, I believe it would violate the intended semantics of
GSSAPI. If I get server credentials with a specific name, it would be
inappropriate for those credentials to be valid accepter credentials
for a name that was not equivalent to the name in the server
credentials for some relation relation.

From: Nicolas Williams <Nicolas.Williams@ubsw.com>
To: Donn Cave <donn@u.washington.edu>
Cc: Sam Hartman <hartmans@mit.edu>, krb5-bugs@mit.edu, krbdev@mit.edu
Subject: Re: krb5-libs/1022: accept_sec_context() specifies principal to rd_req()
Date: Mon, 8 Apr 2002 16:03:56 -0400

Why not use the default credential, GSS_C_NO_CREDENTIAL and then inquire
the context for the acceptor name?

The mechanism should support such behaviour.

Alternatively, is there a way to acquire a default acceptor credential
and then add all the available acceptor credentials to the first one?

Nico

On Mon, Apr 08, 2002 at 12:03:28PM -0700, Donn Cave wrote:
Show quoted text
> It turns out that we were able to solve our particular problem at our
> site more easily in ftpd itself, by resolving the DNS name more accurately
> as I suggested in the very next bug, krb5-appl/1023. If that could be done,
> then I'd have no stake in this issue. In any case it isn't as important
> as the GSS_C_NO_CHANNEL_BINDING support that Jeffrey Altman submitted some
> time back for this file.
>
> In principle, though, I don't see this as throwing away information.
> The information in question is "who did I authenticate as", and that
> is available in the context via gss_inquire_context(). (I think,
> haven't verified that.) The problem is that currently, krb5_rd_req()
> goes on to turn this information into policy, at a level that's not
> accessible to the application. Like telnetd (which I believe checks
> principal name minus instance), ftpd could enforce its own policy in
> this matter, but it has to get past gss_accept_sec_context() first.
>
> Donn Cave, University Computing Services, University of Washington
> donn@u.washington.edu
> _______________________________________________
> krbdev mailing list krbdev@mit.edu
> http://mailman.mit.edu/mailman/listinfo/krbdev
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.


From: Sam Hartman <hartmans@MIT.EDU>
To: Nicolas Williams <Nicolas.Williams@ubsw.com>
Cc: Donn Cave <donn@u.washington.edu>, krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-libs/1022: accept_sec_context() specifies principal to rd_req()
Date: 08 Apr 2002 16:32:09 -0400

Show quoted text
>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams@ubsw.com> writes:

Show quoted text
Nicolas> Why not use the default credential, GSS_C_NO_CREDENTIAL
Nicolas> and then inquire the context for the acceptor name?

I don't think our implementation supports this. I argue that this is
the correct solution and am leaving the bug open in the hope that
someone (either at MIT or in the larger community) will get around to
writing such support.


From: "Douglas E. Engert" <deengert@anl.gov>
To: Sam Hartman <hartmans@mit.edu>
Cc: Nicolas Williams <Nicolas.Williams@ubsw.com>,
Donn Cave <donn@u.washington.edu>, krb5-bugs@mit.edu, krbdev@mit.edu
Subject: Re: krb5-libs/1022: accept_sec_context() specifies principal to rd_req()
Date: Mon, 08 Apr 2002 16:00:51 -0500

Sam Hartman wrote:
Show quoted text
>
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams@ubsw.com> writes:
>
> Nicolas> Why not use the default credential, GSS_C_NO_CREDENTIAL
> Nicolas> and then inquire the context for the acceptor name?
>
> I don't think our implementation supports this. I argue that this is
> the correct solution and am leaving the bug open in the hope that
> someone (either at MIT or in the larger community) will get around to
> writing such support.

Well here is something close which we are using. This allows krb5_rd_req
to select the service ticket to use from any in the keytab. As you point
out, it should check that no desired_name was passed to gss_accquire_creds.



*** ,accept_sec_context.c Wed Jan 9 16:27:43 2002
--- accept_sec_context.c Fri Jan 11 14:52:28 2002
***************
*** 345,355 ****
goto fail;
}

! if ((code = krb5_rd_req(context, &auth_context, &ap_req, cred->princ,
cred->keytab, NULL, &ticket))) {
major_status = GSS_S_FAILURE;
goto fail;
}

krb5_auth_con_getauthenticator(context, auth_context, &authdat);

--- 617,714 ----
goto fail;
}

! if ((code = krb5_rd_req(context, &auth_context, &ap_req, NULL,
cred->keytab, NULL, &ticket))) {
major_status = GSS_S_FAILURE;
goto fail;
}
+ /*
+ * Allow for lax checking of the princ name. This will allow
+ * us to have ssh and ftp use any of the tickets in the
+ * keytab, as we change from dce.anl.gov to KRB5.ANL.GOV
+ * rlogin already allows this. We will check all but realm.
+ */
+ if ( cred->princ && ticket->server) {
+ int i;
+ int nelem;
+ nelem = krb5_princ_size(context, cred->princ);
+ if (nelem == krb5_princ_size(context,ticket->server)) {
+ for (i = 0; i < nelem; i++) {
+ register const krb5_data *p1 =
+ krb5_princ_component(context, cred->princ ,i);
+ register const krb5_data *p2 =
+ krb5_princ_component(context, ticket->server, i);
+ if (p1->length != p2->length ||
+ memcmp(p1->data, p2->data, p1->length)) {
+ major_status = GSS_S_FAILURE;
+ goto fail;
+ }
+ }
+ } else {
+ major_status = GSS_S_FAILURE;
+ goto fail;
+ }
+ }

krb5_auth_con_getauthenticator(context, auth_context, &authdat);
Show quoted text
>
> _______________________________________________
> krbdev mailing list krbdev@mit.edu
> http://mailman.mit.edu/mailman/listinfo/krbdev

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

From: "Donn Cave" <donn@u.washington.edu>
To: <krbdev@mit.edu>
Cc: <krb5-bugs@mit.edu>
Subject: Re: krb5-libs/1022: accept_sec_context() specifies principal to rd_req()
Date: Mon, 8 Apr 2002 14:51:19 -0700

Quoth Sam Hartman <hartmans@mit.edu>:
| >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams@ubsw.com> writes:
|
| Nicolas> Why not use the default credential, GSS_C_NO_CREDENTIAL
| Nicolas> and then inquire the context for the acceptor name?
|
| I don't think our implementation supports this.

True, but apparently by accident - in 1.2.3, anyway, krb5_gss_validate_cred()
is applied to verifier_cred_handle (GSS_C_NO_CREDENTIAL) instead of
cred_handle (acquired by default in this case), so it's guaranteed to
fail. Maybe I misunderstand the point, but I'd change it to

*** 270,270 ****
! major_status = krb5_gss_validate_cred(&code, verifier_cred_handle);
--- 270,270 ----
! major_status = krb5_gss_validate_cred(&code, cred_handle);


| I argue that this is
| the correct solution and am leaving the bug open in the hope that
| someone (either at MIT or in the larger community) will get around to
| writing such support.


How about this, fix the above problem and then pass the name to rd_req()
only if the input credentials weren't GSS_C_NO_CREDENTIAL?

*** 347,350 ****

! if ((code = krb5_rd_req(context, &auth_context, &ap_req, cred->princ,
! cred->keytab, NULL, &ticket))) {
major_status = GSS_S_FAILURE;
--- 347,351 ----

! if ((code = krb5_rd_req(context, &auth_context, &ap_req,
! verifier_cred_handle == GSS_C_NO_CREDENTIAL ? NULL : cred->princ,
! cred->keytab, NULL, &ticket))) {
major_status = GSS_S_FAILURE;

That allows an application to decide its own policy. The application
gets this freedom by supplying GSS_C_NO_CREDENTIAL, which we can safely
assume no existing application does.

Donn Cave, University Computing Services, University of Washington
donn@u.washington.edu
Show quoted text
>Unformatted: