Re: Review of draft-ietf-krb-wg-referrals-13.txt

On 03/09/2012 06:01 PM, Jeffrey Hutzelman wrote:
> I would also like to hear from anyone who has implemented this
> 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.

> 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.

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 protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg