Skip Menu |
 

Download (untitled) / with headers
text/plain 2.6KiB
From wyllys@eagle.wki.test.net Fri Feb 14 15:23:24 2003
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by krbdev.mit.edu (8.9.3) with ESMTP
id PAA02783; Fri, 14 Feb 2003 15:23:24 -0500 (EST)
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA21583
for <krb5-bugs@mit.edu>; Fri, 14 Feb 2003 15:23:21 -0500 (EST)
Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19])
by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23140
for <krb5-bugs@mit.edu>; Fri, 14 Feb 2003 12:23:20 -0800 (PST)
Received: from eagle.wki.test.net (vpn-129-150-16-120.SFBay.Sun.COM [129.150.16.120])
by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1EKNJVL013453
for <krb5-bugs@mit.edu>; Fri, 14 Feb 2003 12:23:20 -0800 (PST)
Received: from eagle.wki.test.net (localhost [127.0.0.1])
by eagle.wki.test.net (8.12.7+Sun/8.12.7) with ESMTP id h1EKNHE1015257
for <krb5-bugs@mit.edu>; Fri, 14 Feb 2003 15:23:17 -0500 (EST)
Received: (from wyllys@localhost)
by eagle.wki.test.net (8.12.7+Sun/8.12.7/Submit) id h1EKNGBL015256;
Fri, 14 Feb 2003 15:23:16 -0500 (EST)
Date: Fri, 14 Feb 2003 15:23:16 -0500 (EST)
Message-Id: <200302142023.h1EKNGBL015256@eagle.wki.test.net>
To: krb5-bugs@mit.edu
From: wyllys.ingersoll@sun.com
Reply-To: wyllys.ingersoll@sun.com
X-send-pr-version: 3.99


Show quoted text
>Submitter-Id: net
>Originator: Wyllys Ingersoll
>Organization: Sun Microsystems, Inc

Show quoted text
>Confidential: no
>Synopsis: kg_seal should check GSS_C_PROT_READY_FLAG value
>Severity: serious
>Priority: medium
>Category: krb5-libs
>Class: sw-bug
>Release: krb5-1.2.7
>Environment:
System: SunOS eagle.wki.test.net 5.10 s10_27 sun4u sparc SUNW,Sun-Blade-100
Architecture: sun4

Show quoted text
>Description: The kg_seal function should not fail if the "established"
flag is not set, but rather should check for the presense of a
subkey AND the GSS_C_PROT_READY_FLAG. This will cause problems
for SPNEGO negotiation later (generating MechListMIC) because
SPNEGO needs the KRB5 mechanism to create a MIC before the
context is fully established.

Show quoted text
>How-To-Repeat:

Show quoted text
>Fix:
[wyllys@eagle 15:20:56 ]gdiff -bw -U 5 k5seal.c k5seal.new
--- k5seal.c Wed May 31 13:17:38 2000
+++ k5seal.new Fri Feb 14 15:20:30 2003
@@ -408,11 +408,11 @@
return(GSS_S_NO_CONTEXT);
}

ctx = (krb5_gss_ctx_id_rec *) context_handle;

- if (! ctx->established) {
+ if (ctx->subkey == NULL || !(ctx->gss_flags & GSS_C_PROT_READY_FLAG)) {
*minor_status = KG_CTX_INCOMPLETE;
return(GSS_S_NO_CONTEXT);
}

if ((code = krb5_timeofday(context, &now))) {
To: rt@krbdev.mit.edu
Subject: [krbdev.mit.edu #1352] Cannot return prot_ready without unwrap working
Date: Thu, 20 Feb 2003 20:16:08 -0500 (EST)
From: hartmans@mit.edu (Sam Hartman)
RT-Send-Cc:


Hi. I actually think our implementation is wrong to set the
prot_ready flag before context establishment is complete. If it sets
that flag then both gss_wrap and gss_unwrap need to work. However
gss_unwrap cannot work because the sequence state is not yet
initialized.


I'm also not sure that RFC 1964 allows this behavior; I don't think
having inconsistent support for prot_ready between implementations is
a good idea.


Why do you need this for SPNEGO? You don't have to generate the
meclistmic until after the underlying mechanism has returned complete.
Date: Fri, 21 Feb 2003 08:50:54 -0500
From: Wyllys Ingersoll <wyllys.ingersoll@sun.com>
To: rt-comment@krbdev.mit.edu
Cc: krb5-prs@MIT.EDU
Subject: Re: [krbdev.mit.edu #1352] Cannot return prot_ready without unwrap working
RT-Send-Cc:
Sam Hartman via RT wrote:
Show quoted text
> Hi. I actually think our implementation is wrong to set the
> prot_ready flag before context establishment is complete. If it sets
> that flag then both gss_wrap and gss_unwrap need to work. However
> gss_unwrap cannot work because the sequence state is not yet
> initialized.
>
>
> I'm also not sure that RFC 1964 allows this behavior; I don't think
> having inconsistent support for prot_ready between implementations is
> a good idea.
>
>
> Why do you need this for SPNEGO? You don't have to generate the
> meclistmic until after the underlying mechanism has returned complete.
>

When using mutual authentication, at the time the initial token is generated,
the status is still "CONTINUE_NEEDED" and the context->established flag
is not set even though the PROT_READY flag is set and the
subkey is available. We think (Nico and I) that gss_get_mic should
be able to succeed in this case. I had not considered the "unseal" case since
that was not a problem. The acceptor side context is already "established" when
the MIC is verified, so it wasnt a problem.

-Wyllys
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1352] Cannot return prot_ready without unwrap working
From: Sam Hartman <hartmans@mit.edu>
Date: Fri, 21 Feb 2003 14:36:29 -0500
RT-Send-Cc:
Show quoted text
>>>>> "Wyllys" == Wyllys Ingersoll via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Wyllys> When using mutual authentication, at the time the initial
Wyllys> token is generated, the status is still "CONTINUE_NEEDED"
Wyllys> and the context->established flag is not set even though
Wyllys> the PROT_READY flag is set and the subkey is available.
Wyllys> We think (Nico and I) that gss_get_mic should be able to
Wyllys> succeed in this case. I had not considered the "unseal"
Wyllys> case since that was not a problem. The acceptor side
Wyllys> context is already "established" when the MIC is verified,
Wyllys> so it wasnt a problem.

But you should not be generating the MIC at this point.
negTokenInit
Negotiation token sent by the initiator to the target, which
contains, for the first token sent, one or more security mechanisms
supported by the initiator (as indicated in the field mechTypes)
and the service options (reqFlags) that are requested to establish
the context. The context flags should be filled in from the
req_flags parameter of init_sec_context().

The mechToken field is optional for the first token sent that all
target implementations would not have to support. However for those
targets that do support piggybacking the initial mechToken, an
optimistic negotiation response is possible. Otherwise the
mechToken is used to carry the tokens specific to the mechanism
selected.





Baize & Pinkas Standards Track [Page 7]

RFC 2478 GSS-API Negotiation Mechanism December 1998


The mechListMIC is an optional field. In the case that the chosen
mechanism supports integrity, the initiator may optionally include
a mechListMIC which is the result of a GetMIC of the MechTypes in
the initial NegTokenInit and return GSS_S_COMPLETE.


That text from 2478 indicates you can only include the mechlistmic in
the initial token when the mechanism returns GSS_S_COMPLETE.
Date: Fri, 21 Feb 2003 15:01:36 -0500
From: Wyllys Ingersoll <wyllys.ingersoll@sun.com>
To: rt-comment@krbdev.mit.edu
Cc: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: [krbdev.mit.edu #1352] Cannot return prot_ready without unwrap working
RT-Send-Cc:
Sam Hartman via RT wrote:
Show quoted text
>>>>>>"Wyllys" == Wyllys Ingersoll via RT <rt-comment@krbdev.mit.edu> writes:
>
>
> Wyllys> When using mutual authentication, at the time the initial
> Wyllys> token is generated, the status is still "CONTINUE_NEEDED"
> Wyllys> and the context->established flag is not set even though
> Wyllys> the PROT_READY flag is set and the subkey is available.
> Wyllys> We think (Nico and I) that gss_get_mic should be able to
> Wyllys> succeed in this case. I had not considered the "unseal"
> Wyllys> case since that was not a problem. The acceptor side
> Wyllys> context is already "established" when the MIC is verified,
> Wyllys> so it wasnt a problem.
>
> But you should not be generating the MIC at this point.
> negTokenInit
> Negotiation token sent by the initiator to the target, which
> contains, for the first token sent, one or more security mechanisms
> supported by the initiator (as indicated in the field mechTypes)
> and the service options (reqFlags) that are requested to establish
> the context. The context flags should be filled in from the
> req_flags parameter of init_sec_context().
>
> The mechToken field is optional for the first token sent that all
> target implementations would not have to support. However for those
> targets that do support piggybacking the initial mechToken, an
> optimistic negotiation response is possible. Otherwise the
> mechToken is used to carry the tokens specific to the mechanism
> selected.
>
>
>
>
>
> Baize & Pinkas Standards Track [Page 7]
>
> RFC 2478 GSS-API Negotiation Mechanism December 1998
>
>
> The mechListMIC is an optional field. In the case that the chosen
> mechanism supports integrity, the initiator may optionally include
> a mechListMIC which is the result of a GetMIC of the MechTypes in
> the initial NegTokenInit and return GSS_S_COMPLETE.
>
>
> That text from 2478 indicates you can only include the mechlistmic in
> the initial token when the mechanism returns GSS_S_COMPLETE.
>

I think it is saying that you can include a mechlistMIC (optionally) and then
return GSS_S_COMPLETE, it does not say that you can only include the
MIC after you get a GSS_S_COMPLETE status. I think that would be impossible
or at least rather useless.

The whole point of the MIC is so the acceptor can verify that the mechList was
not modified in transit, so what good would it be to include the MIC only after
the exchange was completed?

Once the initiator has the initial token from the underlying mech (Krb5) and it
is preparing the SPNEGO NegTokenInit message, it should be able to MIC the
mechList that it is including, even if the current status is GSS_S_CONTINUE_NEEDED,
otherwise, there is no way to send a MIC.

I guess the inclusion of the MIC is optional, but it seems that Kerberos should be
capable of supporting this feature. I've included it in my implementation (at least
for now).

-Wyllys
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1352] Cannot return prot_ready without unwrap working
From: Sam Hartman <hartmans@mit.edu>
Date: Fri, 21 Feb 2003 15:18:51 -0500
RT-Send-Cc:
Show quoted text
>>>>> "Wyllys" == Wyllys Ingersoll via RT <rt-comment@krbdev.mit.edu> writes:


Show quoted text
Wyllys> I think it is saying that you can include a mechlistMIC
Wyllys> (optionally) and then return GSS_S_COMPLETE, it does not
Wyllys> say that you can only include the MIC after you get a
Wyllys> GSS_S_COMPLETE status. I think that would be impossible
Wyllys> or at least rather useless.

No, it is what you should do in the non-mutual authentication case for
Kerberos.

Show quoted text
Wyllys> The whole point of the MIC is so the acceptor can verify
Wyllys> that the mechList was not modified in transit, so what
Wyllys> good would it be to include the MIC only after the
Wyllys> exchange was completed?

That's how SPNEGO works. The last step in the process is the acceptor
verifies the MIC and returns GSS_S_COMPLETE or fails to verify the MIC
and returns GSS_S_FAILURE.

Quoting the RFC:


If the mechanism supports integrity and uses an even number of
messages, then the target must compute a MIC as described above, and
send this in the final NegTokenTarg along with the final mechToken.
The initiator when receiving the last token must require that the
mechListMIC field be present and valid. In the absence of a valid
mechListMIC, the negotiation must fail as if the last context
establishment token was invalid.

In the case that the chosen mechanism supports integrity and uses an
odd number of messages, the final mechanism token will be sent from
the initiator to the target. In this case, there is a tradeoff
between using the optimal number of messages, or using an additional
message from the target to the initiator in order to give the
initiator assurance that no modification of the initiator's mechanism
list occurred. The implementation can choose which tradeoff to make.

When generating the final NegTokenInit message, the NegTokenInit may
optionally include a mechListMIC which is the result of a GetMIC of
the MechTypes in the initial NegTokenInit and return GSS_S_COMPLETE.
The target must check the presence of the MIC computed over the
mechList sent in the initial NegTokenInit. Three cases may then be
considered:

1) If the mechListMIC is present and correct, then
GSS_S_COMPLETE is returned to the target with no token; the
context is established by the target.

2) If the mechListMIC is present but invalid, then the context
establishment must fail. An error major status code is
returned to the target.

3) If the mechListMIC is not included in the final NegTokenInit,
then GSS_S_COMPLETE must be returned to the target with a
token. This token must be a NegTokenTarg, with a MIC included
as described above, and no responseToken. The application will
then send this token back to the initiator, which must verify
that the mechListMIC field is present and valid.




That text makes it quite clear the mechlistmic is not sent as early
as possible but rather as late as possible.
Date: Fri, 21 Feb 2003 14:17:32 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Wyllys Ingersoll <wyllys.ingersoll@sun.com>
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1352] Cannot return prot_ready without unwrap working
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.7KiB
On Fri, Feb 21, 2003 at 03:01:36PM -0500, Wyllys Ingersoll wrote:
Show quoted text
> I think it is saying that you can include a mechlistMIC (optionally) and then
> return GSS_S_COMPLETE, it does not say that you can only include the
> MIC after you get a GSS_S_COMPLETE status. I think that would be impossible
> or at least rather useless.
>
> The whole point of the MIC is so the acceptor can verify that the mechList was
> not modified in transit, so what good would it be to include the MIC only after
> the exchange was completed?

Including it early is nothing more than an optimistic optimization, and,
as such, good, but not absolutely central to security (although, work
avoidance is important if you want to limit DoS attacks, but in this
case I don't think that's a big deal).

Show quoted text
> Once the initiator has the initial token from the underlying mech (Krb5) and it
> is preparing the SPNEGO NegTokenInit message, it should be able to MIC the
> mechList that it is including, even if the current status is GSS_S_CONTINUE_NEEDED,
> otherwise, there is no way to send a MIC.

The RFC2478 text makes sense if one thinks of odd-message exchanges,
such as a Kerberos exchange with no mutual auth, where the client sends
one more message than the server (in the Kerb no mutual auth case the
client sends one message and the server none (unless there's an error,
right?).

But even so, I think it makes plenty of sense to allow the client to
send the MIC as soon as the mech it picks to negotiate for
optimistically is ready to do so.

Show quoted text
> I guess the inclusion of the MIC is optional, but it seems that Kerberos should be
> capable of supporting this feature. I've included it in my implementation (at least
> for now).

I see no text in RFC2478 barring this, though the RFC does not
contemplate it.

Cheers,

Nico
--
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1352] Cannot return prot_ready without unwrap working
From: Sam Hartman <hartmans@mit.edu>
Date: Fri, 21 Feb 2003 15:23:59 -0500
RT-Send-Cc:
Show quoted text
>>>>> "Nicolas" == Nicolas Williams via RT <rt-comment@krbdev.mit.edu> writes:


Show quoted text
Nicolas> But even so, I think it makes plenty of sense to allow
Nicolas> the client to send the MIC as soon as the mech it picks
Nicolas> to negotiate for optimistically is ready to do so.

I'd agree with you except that this is fairly clearly prohibited by
section 3.2.2 of the RFC. I suspect SPNEGO predates prot-ready.
Subject: kg_seal should check GSS_C_PROT_READY_FLAG value
RT-Send-CC: nicolas.williams@sun.com
[hartmans - Fri Feb 21 15:24:02 2003]:

Show quoted text
> >>>>> "Nicolas" == Nicolas Williams via RT <rt-comment@krbdev.mit.edu>
> writes:
>
>
> Nicolas> But even so, I think it makes plenty of sense to allow
> Nicolas> the client to send the MIC as soon as the mech it picks
> Nicolas> to negotiate for optimistically is ready to do so.
>
> I'd agree with you except that this is fairly clearly prohibited by
> section 3.2.2 of the RFC. I suspect SPNEGO predates prot-ready.

Sam, you are correct, I had not noticed that. HOWEVER, the MIT code
seems to want to support PROT_READY, but the support is not complete
and that is what this bug report is about. Regardless of the SPNEGO
issue, the fact is that the MIT krb5 does not support PROT_READY
correctly.

Nico
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1352] kg_seal should check GSS_C_PROT_READY_FLAG value
From: Sam Hartman <hartmans@mit.edu>
Date: Fri, 21 Feb 2003 15:44:53 -0500
RT-Send-Cc:
O, I completely agree that the MIT code is broken with regard to
prot_ready. My question is whether there is a reasonable way to make
prot_ready work for an RFC 1964 mechanism? Reading the base GSSAPI
spec, it sounds like both pwrap and unwrap must work. I.E. in the
Kerberos case, a client must be able to receive both a context token
and a message token from the acceptor, and pass the message token into
gss_unwrap before passing the context token into
gss_accept_sec_context.

I don't know how to handle sequence state in that case. Clearly we
cannot make sequence service available until the context is
established, but I don't even know how to resynchronize state dealing
with messages that may have already been received in order to set that
up.
Subject: kg_seal should check GSS_C_PROT_READY_FLAG value
[guest - Fri Feb 21 15:32:22 2003]:

Show quoted text
> [hartmans - Fri Feb 21 15:24:02 2003]:
> > I'd agree with you except that this is fairly clearly prohibited by
> > section 3.2.2 of the RFC. I suspect SPNEGO predates prot-ready.
>
> Sam, you are correct, I had not noticed that. HOWEVER, the MIT code
> seems to want to support PROT_READY, but the support is not complete
> and that is what this bug report is about. Regardless of the SPNEGO
> issue, the fact is that the MIT krb5 does not support PROT_READY
> correctly.
>
> Nico

Oh, RFC1964 too predates GSS-APIv2. Sigh.

Nico
From: hartmans@mit.edu
Subject: CVS Commit
Our code does not currently support GSS_C_PROT_READY_FLAG so only
return that flag after context establishment. A potential future
addition is to support that flag and return GAP_TOKEN if the initiator
processes a message token before the final context token.


To generate a diff of this commit:



cvs diff -r1.218 -r1.219 krb5/src/lib/gssapi/krb5/ChangeLog
cvs diff -r1.77 -r1.78
krb5/src/lib/gssapi/krb5/accept_sec_context.c
cvs diff -r1.50 -r1.51 krb5/src/lib/gssapi/krb5/gssapiP_krb5.h
cvs diff -r1.66 -r1.67 krb5/src/lib/gssapi/krb5/init_sec_context.c
From: tlyu@mit.edu
Subject: CVS Commit
pullup from trunk


To generate a diff of this commit:



cvs diff -r1.218 -r1.218.2.1 krb5/src/lib/gssapi/krb5/ChangeLog
cvs diff -r1.77 -r1.77.2.1
krb5/src/lib/gssapi/krb5/accept_sec_context.c
cvs diff -r1.50 -r1.50.2.1 krb5/src/lib/gssapi/krb5/gssapiP_krb5.h
cvs diff -r1.66 -r1.66.2.1
krb5/src/lib/gssapi/krb5/init_sec_context.c