Subject: Unclear behavior for krb_cred message especially with regard to GSSAPI

From: [email-masked] (Sam Hartman)
Date: Thu, 20 Feb 2003 18:35:02 -0500 (EST)

Hi.  I've been trying to address GSSAPI credential delegation problems
between the MIT and Heimdal implementations of the Kerberos protocol.
I've run into significant clarity problems with section 3.6 of
Kerberos clarifications and even more problems interpreting how that
specification should interact with RFC 1964.

First, is the nonce that can be included in the krb_cred message a
sequence number in the same sequence number space as the
authenticator, krb_priv and krb_safe messages?

If not, how does the application verify a nonce if one is included?

Why are the timestamp fields required; why don't we use the same
language as we do for krb_priv and krb_safe--you need to either use
timestamps, sequence numbers or deal with replays?

In addition, the ASN.1 allows the timestamps to be optional but 3.6.2
requires they be verified.

Let's assume for the moment that nonces are sequence numbers and work
the same way as all other sequence numbers.

Should a RFC 1964 krb_cred message include a nonce?  It's sort of hard
to do because you may be generating the encrypted message body before
you generate the authenticator.

The RFC 1964 question is mostly for Microsoft and Heimdal.

---

From: Martin Rex <[email-masked]>
Date: Fri, 21 Feb 2003 15:20:48 +0100 (MET)

> The RFC 1964 question is mostly for Microsoft and Heimdal.

As far as I understood Douglas is successfully using my gsskrb.dll
wrapper for Microsoft's W2K Kerberos to delegate credentials to
a Unix-based Kerberos implmenentation (MIT's I assume...),
so there seems to be some interoperability among some of
the implementations...

However, as I'm not a Kerberos implementor, I never looked at these
parts of the specs...

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 21 Feb 2003 10:36:30 -0600

> so there seems to be some interoperability among some of

I believe I did get that to work, but that was some time ago. 
Is there a newer version? If so I could try it again.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Feb 2003 14:25:18 -0500

>>>>> "Douglas" == Douglas E Engert <[email-masked]> writes:

    Douglas> Martin Rex wrote:
    >> 
    >> Sam Hartman wrote:
    >> >
    >> > Hi.  I've been trying to address GSSAPI credential delegation
    >> problems > between the MIT and Heimdal implementations of the
    >> Kerberos protocol.  > I've run into significant clarity
    >> problems with section 3.6 of > Kerberos clarifications and even
    >> more problems interpreting how that > specification should
    >> interact with RFC 1964.
    >> >
    >> As far as I understood Douglas is successfully using my
    >> gsskrb.dll wrapper for Microsoft's W2K Kerberos to delegate
    >> credentials to a Unix-based Kerberos implmenentation (MIT's I
    >> assume...), so there seems to be some interoperability among
    >> some of the implementations...

    Douglas> I believe I did get that to work, but that was some time
    Douglas> ago.  Is there a newer version? If so I could try it
    Douglas> again.

I didn't have any problems using the old version to do some interop
testing last summer.  I also found the gss sample implementation in
the MSDN SDK can receive delegated credentials from an MIT client.

---

From: Love <[email-masked]>
Date: Thu, 27 Feb 2003 18:31:30 +0100

> the same way as all other sequence numbers.

This seems reasonable, unfortionatly this is not how heimdal does it.

> you generate the authenticator.

For interop reason it seem it shouldn't include/verify the nounce/seqence
number. If I understand it correctly should not verify the timestamp either
when used in RFC 1964 ?

Love

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 27 Feb 2003 11:50:32 -0600

Hmmm, looking at clarifications:

 - KRB-CRED has no sequence number

 - KRB-CRED has an optional nonce; this nonce is supposed to be provided
   by the KRB-CRED *receipient*, but no mechanism for it to do so is
   provided!

   [In the case of RFC1964, there is no way that the receipient can
   provide such a nonce prior to the client sending its KRB-CRED
   (because the KRB-CRED is sent within the AP-REQ).]

 - The time fields of KRB-CRED are optional

Ergo, there is no issue.  The nonce field of the KRB-CRED should just
not be used in RFC1964 and should be ignored if used.  There is no
sequence number.

As for the time fields of KRB-CRED are optional and, in the case of
RFC1964, redundant, since the enclosing AP-REQ too has time fields
(non-optional); RFC1964 implementations should not use the time fields
of KRB-CRED and should probably ignore them when present.

Cheers,

Nico

---

From: Love <[email-masked]>
Date: Thu, 27 Feb 2003 20:00:27 +0100

>    by the KRB-CRED *receipient*, but no mechanism for it to do so is

krb5-1.2.6/src/lib/krb5/krb/rd_cred.c:krb5_rd_cred_basic() line 84
    replaydata->seq = encpart.nonce;

and then later krb5_rd_cred() does this:

    if (auth_context->auth_context_flags & KRB5_AUTH_CONTEXT_DO_SEQUENCE) {
        if (auth_context->remote_seq_number != replaydata.seq) {
            retval =  KRB5KRB_AP_ERR_BADORDER;
            goto error;
        }
        auth_context->remote_seq_number++;
    }

so, MIT code assumes that the nouce is a sequence number.

I think there is no issue that the gssapi krb5 must not use sequence number
for krb-cred.

So:

- KRB-CRED has sequence number, its just named nonce. This should be
  clearified in clarifications or the MIT code is just wrong since it uses
  the nonce as a sequence number.

- 1964 (GSSAPI KRB5) must not let the KRB-CRED use up a sequence number
  when doing delegation.

Currently this is not a issue for GSSAPI KRB5 since no GSSAPI krb5
implementator uses up a sequence number for the KRB-CRED message (since all
implementation more or less interoperate pendning other "features").

However:

There is a disagreement if KRB-CRED uses up a sequence number when doing
'plain' krb5. MIT does, heimdal doesn't. This is what I (and I assume Sam)
want to have clearifed.

Love

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 27 Feb 2003 13:12:46 -0600

That's not what clarifications says.  It calls the nonce a nonce and
says nothing about it being like a sequence number.  It might have been
better if it had been a sequence all along, but that's not what it is.

I think the MIT code you quote is incorrect and should be fixed.
Besides being wrong about treating the nonce as a sequence number, it is
wrong in that it expects the nonce to always be sent, even though it's
optional (it assigns a default value of 0, but this is implicit in the
way the structure is decoded).

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 27 Feb 2003 13:30:41 -0600

Furthermore, the correct thing for implementors to do, if clarifications
is not changed wrt this issue, would be to have an API for KRB-CRED
recipients to tell the Kerberos library what the nonce is expected to
be, if anything, and only if the application has used this API should
the Kerberos library check that nonce.

As for the WG, I might suggest that use of the nonce field of KRB-CRED
(EncKrbCredPart, to be correct) be deprecated or otherwise a new
guideline be given for its used, in clarifications, and that a KRB-CRED
sequence number or a way to negotiate said nonce be put on the
extensions agenda.

The KRB-CRED nonce could, perhaps, be required to be set to the same
value as the sequence number from the AP-REP, or, failing that, from the
AP-REQ, or, failing that, the KRB-CRED nonce should be ignored.  I think
I like this approach, provided it won't cause interop problems.

Cheers,

Nico

---

From: Sam Hartman <[email-masked]>
Date: Thu, 27 Feb 2003 18:10:09 -0500

>>>>> "Love" == Love  <[email-masked]> writes:

    >> Should a RFC 1964 krb_cred message include a nonce?  It's sort
    >> of hard to do because you may be generating the encrypted
    >> message body before you generate the authenticator.

    Love> For interop reason it seem it shouldn't include/verify the
    Love> nounce/seqence number. If I understand it correctly should
    Love> not verify the timestamp either when used in RFC 1964 ?

I think I am OK with not generating a nonce.  However I am not OK with
forbidding verification of nonces that do exist.  Basically if you
want to treat RFC 1964 specially you need to provide significant
justification for your decision.  The basic krb_cred clearly makes the
nonce optional, so not using it is a valid option.  However it seems
that for most other messages we verify the field if present.  If we
are going to do something different for RFC 1964 we should have a very
strong reason.