Subject: ID-review draft-ietf-krb-wg-kerberos-referrals-08

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 5 Jul 2006 04:18:00 -0700

First of all, this is the best revison of the referrals ID. Great work!
This is really close now.

1) section 1, pragraph 4, I think the word "you" actually means the
administrator of the local realm.

 REPLACE OLD
You could give that remote server an identity in the local
   realm and then have that remote server maintain a separate secret for
   each alias it is known as.
  Alternatively you could arrange to have
   the local realm issue a referral to the remote realm and notify the
   requesting client of the server's remote name that should be used in
   order to request a ticket.

 With NEW:
The administrator in the local realm could give that remote server an
identity in the local
   realm and then have that remote server maintain a separate secret for
   each alias it is known as.
 Alternatively the administrator in the local realm could arrange to
have
   the local realm issue a referral to the remote realm and notify the
   requesting client of the server's remote name that should be used in
   order to request a ticket.

2) section 1, pragraph 5, is there any difference between the mechanism
in this ID with the cross-realm authentication defined in RFC4120?
If there is no difference, then remove the following sentence: " and
provide a mechanism for
   the KDC to determine the trusted realm authentication path by being
   able to generate referrals to other realms in order to locate
   principals"

3) section 3, maybe we can benefit from defining the referral ticket
first, although a referral ticket is most likely a referral TGT.

REPLACE OLD
A referral TGT is a cross realm TGT that is
   returned with the server name of the ticket being different from the
   server name in the request [RFC4120].

With NEW:

  A ticket is a referral ticket if the server name of the ticket being
different from the
   server name in the request [RFC4120]. A referral TGT is a referral
ticket with the server
Name being the name of a TGS.

4) section 5, first paragraph, let's the exsting deployed logic, and the
text is not clear when it just says the realm does not correspond to
anything but gives no specific value it should be. Also the updated text
below is consistent with the text later in the ID.

REPLACE OLD
   This utilizes a new client principal name type, as the AS-REQ message
   only contains a single realm field, and the realm portion of this
   name doesn't correspond to any Kerberos realm

With NEW:

   This utilizes a new client principal name type, as the AS-REQ message
   only contains a single realm field, and the realm portion of this
   name corresponds to the Kerberos realm with which the request is
made.

5) section 5, first paragraph, let's use the exsting deployed logic

REPLACE OLD 
The KDC will recognize this
   name type and then transform the requested name into the true
   principal name.  The true principal name can be using a name type
   different from the requested name type.  Typically the true principal
   name will be a NT-PRINCIPAL [RFC4120].

With NEW:
The KDC will recognize this
   name type and then transform the requested name into the true
   principal name if the client account resides in the local realm.  The
true principal name can be using a name type
   different from the requested name type.  Typically the true principal
   name will be a NT-PRINCIPAL [RFC4120].

6) sectoin 5, paragraph 5, add extensibility marker, and it is not clear
to me what is a returned session key

Replace OLD

   PA-CLIENT-CANONICALIZED ::= SEQUENCE {
     names          [0] SEQUENCE {
       requested-name [0] PrincipalName,
       real-name      [1] PrincipalName
     },
     canon-checksum [1] Checksum
   }

The canon-checksum field is computed over the DER encoding of the
   names sequences, using the returned session key and a key usage value
   of (TBD).

With NEW:

     ReferalInfo ::= SEQUENCE {
       requested-name [0] PrincipalName,
       mapped-name    [1] PrincipalName,
       ...
     }
PA-CLIENT-CANONICALIZED ::= SEQUENCE {
     names          [0]  ReferalInfo,
     canon-checksum [1] Checksum
   }

The canon-checksum field is computed over the DER encoding of the
   type ReferalInfo, using the AS reply key and a key usage value
   of (TBD).

7) section 5, pargraph 6, is it better with the following change?

Replace OLD 
or the requested-name field doesn't match the originally-
   transmitted request, 

With NEW:
or the requested-name field doesn't match the originally-
   transmitted client name in the request, 

8)section 5, pargraph 6, real-name vs mapped-name? I like the later

9) extensibilty marker in AD-LOGIN-ALIAS, define a new type for the
login-alias and insert the marker

   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD --
     login-alias  [0] PrincipalName,
     checksum     [1] Checksum
   }

10) for AD-LOGIN-ALIAS to work, wrapping it in AD-KDC-ISSUED sounds
right, and how is it copied from cross-realm referrals TGTs?

11) section 6, paragraph 2, it is not clear what does the referral mean
here:
Replace OLD 

The client SHALL NOT use a cname returned from a referral until that
   name is validated.

With NEW:
   The client SHALL NOT use a cname returned from a kerberos error until
that
   name is validated.

12) section 6, pagraph 2, it is not clear to me what is an error "from"
the request:

REPLACE OLD 
it will issue a
   new AS request with the same client principal name used to generate
   the first referral to the realm specified by the realm field of the
   Kerberos error message from the first request

With NEW:

  it will issue a
   new AS request with the same client principal name used to generate
   the first referral to the realm specified by the realm field of the
   Kerberos error message corresponding to the first request.

13) section 6, paragraph 6, the mapped names are sent in the signed
padata too, right?

Replace OLD:

The true principal name of the client, returned in AS-REQ, can be
   validated in a subsequent TGS message exchange where its value is
   communicated back to the KDC via the authenticator in the PA-TGS-REQ
   padata [RFC4120].

With NEW:

The true principal name of the client is also in the encrypted ticket,
returned in AS-REQ, can be
   validated additionally in a subsequent TGS message exchange where its
value is
   communicated back to the KDC via the authenticator in the PA-TGS-REQ
   padata [RFC4120], or in the authenticatior of a subsequent AP
exchange.

14) section 7, first paragraph, shall we limit ourself to referral TGTs?

REPACE OLD 
The primary difference in server referrals is that the KDC MUST
   return a referral TGT rather than an error message as is done in the
   client referrals. 

With NEW:

The primary difference in server referrals is that the KDC MUST
   return a referral ticket rather than an error message as is done in
the
   client referrals. 

15)section 7, what is "an option checksum"?

(Note that with the forthcoming rfc1510ter, the AS-REP may include an
   option checksum of the AS-REQ, in which case this check would no
   longer be necessary.)

16) section 7, last pargraph, I do not understand what does the text
mean,
 in a user2user authentication, the client knows the server's name, and
the server knows the client name via 
the info in AD-LOGIN-ALIAS or via MS PAC.

17) section 9, is cross-realm routing already in RFC4120?

18) section 10, this is problematic, since the referral TGT is not
specfic to a specific service principal, it will only make
sense to un-tie a referral info of a particular service from the
lifetime referral TGT, the caching should be done per-principal name and
its life-time can be a local policy setting.

19) secton 11, I suggest that the alias being used in the request should
always be included, but it is optional to include other/additional
aliases.

20) appedix A, PKINIT is now RFC4556.

21) appedix A, last pagragraph, the client alias UPN is unqiue, but the
server aliase is not (it is called SPN, it is a multi-value attrbiute in
microsoft AD)

Replace OLD:

   While we might want to permit multiple aliases to exist and even be
   reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
   one alias to exist, so this question had not previously arisen.

With NEW:

   While we might want to permit multiple aliases to exist and even be
   reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
   one alias as the NT-ENTERPRISE name to exist, so this question had
not previously arisen.