r11940: Love has clarified why this code does what it does.

Andrew Bartlett
(This used to be commit 9b3dedbc0bb12897a8f9bd4ec864de26b3835981)

2 files changed, 6 insertions, 8 deletions

diff --git a/source4/auth/kerberos/kerberos-notes.txt b/source4/auth/kerberos/kerberos-notes.txt
index 25524ebba7..58a4159a7e 100644
--- a/source4/auth/kerberos/kerberos-notes.txt
+++ b/source4/auth/kerberos/kerberos-notes.txt
@@ -179,14 +179,6 @@ Other odd things:
    allow multiple passwords per account in krb5.  (I think this was
    intened to allow multiple salts)
 
- - When sending the enc-type negotiation, we call get_pa_etype_info if
-   there are only 'old' enc types present, but always call
-   get_pa_etype_info2.  It would seem more logical to have an
-   either/or, or only send both to clients that show signs of knowing
-   about the old enc types.
- - Perhaps this is to cope with clients that expect the older info in
-   the first position?  (Comments needed)
-
 State Machine safety
 --------------------
 
diff --git a/source4/heimdal/kdc/kerberos5.c b/source4/heimdal/kdc/kerberos5.c
index ccfa35b638..565c7478f9 100644
--- a/source4/heimdal/kdc/kerberos5.c
+++ b/source4/heimdal/kdc/kerberos5.c
@@ -1099,6 +1099,12 @@ _kdc_as_rep(krb5_context context,
 	pa->padata_value.data	= NULL;
 #endif
 
+	/* RFC4120 requires:
+            - If the client only knows about old enctypes, then send both info replies
+              (we send 'info' first in the list).
+            - If the client is 'modern', because it knows about 'new' enc types, then 
+              only send the 'info2' reply.
+	*/
 	/* XXX check ret */
 	if (only_older_enctype_p(req))
 	    ret = get_pa_etype_info(context, config, &method_data, &client->entry,