Hi, >> What I'm left wondering is, if the client's KDC knows what delegations >> are permitted, as is the case with FreeIPA, is it not simpler to pass on >> the additional tickets for smtp/ and imap/ in an AD structure in the >> webmail ticket? > > This is a potential optimization I have been thinking about before, but > requires clients that understand how to extract these tickets and put > them in their ccache. Perfectly doable though.
I'm wondering about this for the design of TLS-KDH. I have a couple of flags in mind that request for ticket properties, and I'm wondering if S4U2Proxy should be added as a flag. S4U2Proxy is not an IETF standard, another is that it also lacks a number of quality signs -- such as exchangeable ciphers, portability and I have security concerns about concatenating strings without separator marks. So my tendency is not to specify such a flag (but leave it open for extensions by others) in TLS-KDH, but instead consider having a flag to request this ticket-carrying AD. That is a New Thing, but at least it is absolutely clear and downright simple. Especially if the AD contains the standardised KRB-CRED message; the MIT krb5 API has krb5_rd_cred() to easily decode that, and I assume Heimdal has something similar. Do tell me if I'm thinking silly thoughts :) >> I must still be missing why S4U2Proxy works the way it does. It may be >> that it was designed with more flexibility in mind though, that probably >> suits the mindset of its inventors. > > S4U2Proxy is built this way because in the Microsoft implementation it > is the receiving service that enforces access control. IIRC the KDC does > not, it just either always allow proxy for any target or for none. Yes, that also matches with what the S4U2Self approach does; it also grabs control based on things that scare me. I suppose the implicit assumption is that it functions within a realm, which makes it less usable for more general use when TLS-KDH gets to crossover to foreign realms. Thanks, -Rick ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos