diff options
| -rw-r--r-- | source4/auth/kerberos/kerberos-notes.txt | 8 | ||||
| -rw-r--r-- | source4/heimdal/kdc/kerberos5.c | 6 |
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, |