Subject: TGS-REP processing

From: [email-masked]
Date: Tue, 15 Oct 2002 06:17:05 +0200

Section 3.3 of draft-ietf-krb-wg-kerberos-clarifications-01.txt:

,----
| The primary difference is that encryption and decryption in the TGS
| exchange does not take place under the client's key. Instead, the
| session key from the ticket-granting ticket or renewable ticket, or
| sub-session key from an Authenticator is used.
...
| The TGS reply (KRB_TGS_REP) contains the requested credentials,
| encrypted in the session key from the ticket-granting ticket or
| renewable ticket, or if present, in the sub-session key from the
| Authenticator (part of the authentication header).
`----

Section 3.3.4:

,----
| When the KRB_TGS_REP is received by the client, it is processed in the
| same manner as the KRB_AS_REP processing described above. The primary
| difference is that the ciphertext part of the response must be decrypted
| using the session key from the ticket-granting ticket rather than the
| client's secret key. The server name returned in the reply is the true
| principal name of the service.
`----

Should the response be decrypted using the session key in the TGT
ticket or, if present, the sub-session key in the Authenticator?

The latter text implies that the sub-session Authenticator key must
not be used, but the former text allows it.

Furthermore, looking in 3.1.5 to see how to process the KRB_TGS_REP:

,----
| If the reply message type is KRB_AS_REP, then the client verifies that
| the cname and crealm fields in the cleartext portion of the reply match
| what it requested.
`----

Does this mean the receiver should not check the cname and crealm
fields at all, or should it check them against the AP-REQ?  The
security implications of (not) doing the verification aren't clear to
me.

Continuing in 3.1.5:

,----
| It also verifies that the sname and srealm in the response match those
| in the request (or are otherwise expected values)
`----

How should the client verify the sname/srealm in a TGS?  Remember
3.3.4 saying "The server name returned in the reply is the true
principal name of the service" above.

Thanks.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Oct 2002 08:57:13 -0400

>>>>> "s" == ietf-krb-wg  <simon> writes:

    s> Section 3.3 of
    s> draft-ietf-krb-wg-kerberos-clarifications-01.txt: ,---- | The
    s> primary difference is that encryption and decryption in the TGS
    s> | exchange does not take place under the client's key. Instead,
    s> the | session key from the ticket-granting ticket or renewable
    s> ticket, or | sub-session key from an Authenticator is used.
    s> ...  | The TGS reply (KRB_TGS_REP) contains the requested
    s> credentials, | encrypted in the session key from the
    s> ticket-granting ticket or | renewable ticket, or if present, in
    s> the sub-session key from the | Authenticator (part of the
    s> authentication header).  `----

    s> Should the response be decrypted using the session key in the
    s> TGT ticket or, if present, the sub-session key in the
    s> Authenticator?

Decrypt using subkey if present else session key.  I forwarded this
bug to Cliff a week or to ago; if it is not fixed on
http://www.kerberos.us in the updated sections you should send mail to
[email-masked].
    s> Furthermore, looking in 3.1.5 to see how to process the
    s> KRB_TGS_REP:

    s> ,---- | If the reply message type is KRB_AS_REP, then the
    s> client verifies that | the cname and crealm fields in the
    s> cleartext portion of the reply match | what it requested.
    s> `----

    s> Does this mean the receiver should not check the cname and
    s> crealm fields at all, or should it check them against the
    s> AP-REQ?  The security implications of (not) doing the
    s> verification aren't clear to me.

It seems fairly clear to me from this text that the client verifies
against the original request.

    s> Continuing in 3.1.5:

    s> ,---- | It also verifies that the sname and srealm in the
    s> response match those | in the request (or are otherwise
    s> expected values) `----

    s> How should the client verify the sname/srealm in a TGS?
    s> Remember 3.3.4 saying "The server name returned in the reply is
    s> the true principal name of the service" above.

I think the comment in 3.3.4 is a hold over from server name
canonicalization which was removed.  IT's unclear what an
implementation should do; Windows may sometimes return a different
service name, although long term (extensions presumably) it will not
do that.

I am not sure you get any security benefit from verifying that field;
you could just as easily create a similar DOS attack by corrupting the
ticket without corrupting the server name.

On the other hand, I believe that implementations that strictly verify
the server name would conform to the spec.   

If someone had proposed specific behavior in this regard a few weeks
ago, I'd probably have agreed to either SHOULD check, SHOULD NOT
check, or with some convincing MUST NOT check.  However I don't think
the issue of what to do about sname/srealm is worth modifying the text
at this point.

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Oct 2002 22:28:16 +0200 (MET DST)

> principal name of the service" above.

As Sam mentioned, the confusion comes from the canonicalization idea
in Microsoft's Kerberos implementation.

One of the reasons why I wanted canonicalization dropped was that
it is totally incompatible with GSS-API based mutual authentication.

The Microsoft approach has several serious problems, which become
obvious as soon as you add non-Microsoft machines to a Realm
that is managed by a Microsoft KDC (Active Directory) and set up
services on that non-microsoft machines that do *NOT* use
the host/f.q.d.n service principal.

I have been unable to create arbitrary hostbased service principals
in a Microsoft REALM so that I can export/create a keytab containing
the non-host hostbased service principal and it's key.

-Martin