Kerberos U2U and KINK GETTGT (#3, #44,...)

"KAMADA Ken'ichi" <[email protected]> Fri, 25 Feb 2005 11:44:11 +0900
Newsgroups gmane.ietf.kink
Message-ID <20050225114411XP%[email protected]>
The designer of GETTGT and/or Kerberos people,

The current KINK_TGT_REQ carries only a realm name, but
why does it have been specified in that way?

That is, sending the responder's full principal name seems
reasonable to me.

- In non-U2U case, the initiator is expected to know the responder's
  principal name.  I think it is also true in U2U case.  (Here, I
  don't care where it is from; PAD, generated form FQDN, etc.)

- If the initiator specifies the responder's principal (instead of the
  realm), the U2U sequence seems to work well as follows.

  1) The initiator somehow decide to use U2U mode.  (I think this is
  a Kerberos issue and not to be specified in KINK.)
     a) manually preconfigured.
     b) KDC_ERR_MUST_USE_USER2USER in the reply to TGS-REQ.
     c) KRB_AP_ERR_USER_TO_USER_REQUIRED in the reply to AP-REQ.

  2) The initiator send KINK_TGT_REQ with the responder's principal
  name.

  3) The responder's returns its TGT.
  The cname field of the TGT must be the same with the specified
  principal.  (Regarding the sname field, I will write another mail
  with the consideration of cross-realm issues.)

  4) The initiator do TGS-REQ; with the ENC-TKT-IN-SKEY option,
  with the TGT as the additional-ticket field, and with the responder's
  principal as the sname field.

  5) The KDC makes a service ticket and returns it.
  At this time, the KDC compares the sname field in the TGS-REQ and
  the cname field in the TGT, so the responder's principal name
  is authenticated.

  6) The initiator uses the service ticket with the USE-SESSION-KEY
  flag.

  7) continue as usual

thanks,
-- 
KAMADA Ken'ichi <[email protected]>