Subject: [Ietf-krb-wg] Review of draft-ietf-krb-wg-referrals-13.txt

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 09 Mar 2012 18:01:39 -0500

Below is my review of referrals.  This document looks pretty good; there
are only a few issues.  As usual, I'd like to see some resolution to all
of these, though some may not necessarily require a change to the
document.  Items 1, 4, 8, and 9 are blockers; they must be resolved
before the document can progress.

I would also like to hear from anyone who has implemented this
specification or is planning to do so.

-- Jeff

1) The abstract needs to specifically mention that this document
    updates RFC4120.

2) In the last paragraph of section 1, s/compliments/complements/

3) Why is AD-LOGIN-ALIAS a one-element SEQUENCE?

4) In the last paragraph of section 6, s/MUST not/MUST NOT/; that
   is, make the NOT be uppercase.  This is required for consistency
   with the terms as defined by RFC2119.

5) In the second paragraph of section 7, the phrase "KDC reply structure" 
   seems odd.  Perhaps s/ structure// ?

6) Section 7, paragraph 6, begins "The true principal name of the
   client, returned in AS-REQ...".  I think AS-REP is meant here.

7) Section 11 includes a new PA type PA-REQ-ENC-PA-REP, which has
   a rather unwieldy name.  It looks like this is always empty in
   requests, and in replies contains a checksum, rather than encrypted
   data.  It seems like this could have a better name, such as
   PA-REQ-CHECKSUM.

8) Section 11 refers to a key usage value KEY_USAGE_AS_REQ.  But this
   is not called out in section 12 (Number assignments).  Is this value
   present in the key usage registry?

9) Various acronyms need to be expanded on first use:
   Note that expansion in the abstract is not sufficient to cover uses
   elsewhere in the document.
   - TGT (abstract)
   - AS, TGS (section 1, graf 1)
   - KDC (section 1, graf 2)

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Fri, 09 Mar 2012 19:28:40 -0500

> specification or is planning to do so.

To the best of my understanding, MIT krb5 has had client support for
server referrals since 1.6 and for client referrals since 1.7 (but I
have a vague memory that it had important bugfixes in 1.8).  We've had
KDC support for server referrals based on the KDC's [domain_realm]
mapping since 1.7.  We have had KDC support for client referrals since
1.7 if the KDB back end produces them, but neither of our provided back
ends produce them.  We have had FAST negotiation support since 1.8.

Of course, these implementations were done based on the versions of the
draft at the time (or and at times based on AD behavior, or based on
thoughts in Sam's head in the case of FAST negotiation, which have since
appeared in the draft).  But I believe our implementations are
compatible with the current draft.

>    data.  It seems like this could have a better name, such as

In a request, the name means "request encrypted padata in reply", and
indicates that the implementation is capable of accepting the extra
ASN.1 field in the EncKDCRepPart (which is not defined as extensible in
RFC 4120).  PA-REQ-CHECKSUM would be more descriptive of what the type
tag means in the encrypted padata part of the reply, but less
descriptive of what it means in a request.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Sun, 11 Mar 2012 15:34:31 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:
    Jeffrey> 3) Why is AD-LOGIN-ALIAS a one-element SEQUENCE?

I've added an extensibility marker, which is why I think it was a
one-element sequence.

    Jeffrey> 7) Section 11 includes a new PA type PA-REQ-ENC-PA-REP,
    Jeffrey> which has a rather unwieldy name.  It looks like this is
    Jeffrey> always empty in requests, and in replies contains a
    Jeffrey> checksum, rather than encrypted data.  It seems like this
    Jeffrey> could have a better name, such as PA-REQ-CHECKSUM.

I'd prefer  to keep the wording: we had a fair bit of WG discussion of
this name going back to Larry's original proposal
and Greg has explained why the current name  makes sense.

    Jeffrey> 8) Section 11 refers to a key usage value KEY_USAGE_AS_REQ.
    Jeffrey> But this is not called out in section 12 (Number
    Jeffrey> assignments).  Is this value present in the key usage
    Jeffrey> registry?

Section 12  is not actually a listing of numbers that have been
assigned; this document doesn't have one of those.
Instead section 12 is a TBD list of actions where we're waiting for Tom.

Based on our experience with OTP preauth I would recommend against
adding a section describing all the number assignments that have been
made for this spec.
    Jeffrey> 9) Various acronyms need to be expanded on first use: Note
    Jeffrey> that expansion in the abstract is not sufficient to cover
    Jeffrey> uses elsewhere in the document.  - TGT (abstract) - AS, TGS
    Jeffrey> (section 1, graf 1) - KDC (section 1, graf 2)

    Jeffrey> _______________________________________________ ietf-krb-wg
    Jeffrey> mailing list [email-masked]
    Jeffrey> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

However there is a blocking item: Tom needs to assign ad-login-alias.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 15 Mar 2012 16:47:09 -0400

> and Greg has explained why the current name  makes sense.

OK.

> adding a section describing all the number assignments that have been

We've discussed this, and as a result decided to remove that section
entirely.  -14 reflects this, and also the assignment for
AD-LOGIN-ALIAS.

>     Jeffrey> (section 1, graf 1) - KDC (section 1, graf 2)

This didn't happen before -14 was submitted.  I'm adding an RFC-Editor
note to the writeup to handle these.

-- Jeff

---

From: Tom Yu <[email-masked]>
Date: Wed, 21 Mar 2012 10:44:23 -0400

>    present in the key usage registry?

This number is present in the key usage registry.

While I was rereading the document, I found the following error in
Appendix A:

          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
                 referred-name   [1] PrincipalName OPTIONAL,
                 referred-realm  [0] Realm
          }}

should probably be:

          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
                 referred-realm  [0] Realm,
                 referred-name   [1] PrincipalName OPTIONAL
          }

at least according to
http://www.isoc.org/isoc/conferences/ndss/01/papers/trostle.pdf, which
I believe is a correct copy of [XPR].  I haven't confirmed whether
Windows actually encodes it that way.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Wed, 21 Mar 2012 11:52:33 -0400

>                  referred-name   [1] PrincipalName OPTIONAL

I can confirm that the ASN.1 encoder we had in our tree matches the
element order of the corrected definition ([0] realm, [1] principal
name), although nothing in our tree actually uses the encoder.  But this
is evidence of what eDirectory did.

Heimdal uses:

	PA-ServerReferralData ::= SEQUENCE {
		referred-realm          [0] Realm OPTIONAL,
		true-principal-name     [1] PrincipalName OPTIONAL,
		requested-principal-name [2] PrincipalName OPTIONAL,
		referral-valid-until     [3] KerberosTime OPTIONAL,
		...
	}

which matches the corrected definition up until the additional elements
and extensibility marker.  However, Heimdal's code confuses me because
it appears to look for an element in the KDC-REP's pa-data sequence,
with the element's value encrypted in the session key.  The draft
description suggests that the code should be looking for a pa-data
element in the EncKDCRepPart's encrypted-pa-data sequence.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg