Subject: possible fixes for some name canonicalizations issues

From: Ken Raeburn <[email-masked]>
Date: Mon, 11 Dec 2000 18:03:22 -0500

In talking about this with Sam and others last night I realized that
some of the things I've been complaining about may be easier to fix
than I thought, though they require adding more content to messages.

1) No means to do name canonicalization if you're not authenticating.

   Is it okay to require credentials in order to do canonicalization?
   If so, how about this: Send a TGS_REQ for the service name you
   have.  If you get back a TGS_REP for a service, great; pull out the
   name and throw out the credentials.  If you get back a TGS_REP for
   a TGT service, ask again in the specified realm.  If you get back a
   KRB_ERROR because policy prohibits you from authenticating to that
   service, we can add to the specification that the {realm,sname} in
   the KRB_ERROR must be the canonical name, and the checksum must be
   used.  As long as the checksum is present, it's still a secure
   exchange with the KDC.

   If we have to be able to do name canonicalization without any sort
   of credentials, either client-side (tickets) or server-side
   (tickets automatically acquired via service key), I think we just
   lose.  But maybe GSSAPI should be changed if that's the case.

2) Can't refer to another realm and specify a different service name
   to give to that realm's KDC.  The local KDC can tell you a
   different service name or a different realm name, but not both.
   This comes up in the "gnuftp.raeburn.org CNAME ftp.gnu.org" type of
   case I've mentioned.

   Except ... the KDC-REP structure includes padata and ticket
   extensions fields that are extensible.  We could add a required
   value to one of them -- perhaps only in the case where you return a
   TGT when not asked -- that contains signed information about the
   principal name to ask for in the other realm.  (It would have to be
   required, otherwise a man-in-the-middle could make it go away.)
   Signing would be done using the session key for the TGS.

3) Secure canonicalization of service name in AS_REQ.

   If the response is an AS_REP, we need a way to tell that the
   altered server name wasn't a result of a MITM attack on the AS_REQ
   message.  Again, the KDC-REP extensible fields could have a new
   required value added when name canonicalization happens, indicating
   what the original principal name (in the AS_REQ message) was, and
   signed using the same key as protects the AS_REP.  If it doesn't
   match what the client requested, the messages were altered in
   transit.

4) Client name needs referral to another realm, and server name needs
   canonicalization of some sort.

   The above fixes wouldn't work for this case, and I'm not even sure
   which KDC should be doing the canonicalization anyways.

The other-principal-name datum would probably look something like:

    PrincipalAndNonce ::= SEQUENCE {
		    name[0]	PrincipalName,
		    nonce[1]	INTEGER		-- copied from KDC_REQ
    }
    SignedPrincipal ::= SEQUENCE {
		    name-and-nonce[0]	PrincipalAndNonce,
		    cksum[1]	Checksum
    }
    {PA,TE}-ORIGINAL-SERVER-PRINCIPAL ::= SignedPrincipal
    {PA,TE}-REMOTE-SERVER-PRINCIPAL ::= SignedPrincipal

with the checksum computed over the encoding of the 'name-and-nonce'
field, and appropriate PA- or TE- numbers assigned.  I don't have a
strong opinion on whether it'd be a pa-data or ticket extension;
conceptually it seems like an abuse of either, but, well, I think I'd
rather abuse them than leave the facility both in and inadequate.

The nonce is needed because multiple exchanges may be made with the
same key, and these extension fields aren't packed in with the other
encrypted data in the same response, so a MITM could pick apart
multiple messages and mix-and-match components.  (In a TGS_REQ
exchange, a subsession key would help, but it's not required.)

The extension field would be required to prevent a MITM from
discarding the field from a response; a flag bit in a protected part
of the message (probably in 'flags' in EncKDCRepPart) could also let
us know of a cases where the information can be omitted, namely, when
no name change is done.  Perhaps the bit should be set to indicate
that a name change *was* done, and clear if it wasn't, making the
no-change case more directly compatible with RFC1510.

Thoughts?

Ken