Constrained Delegation and PAC : Realm crossover
Rick van Rein
rick at openfortress.nl
Tue Oct 20 11:58:32 EDT 2015
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
More information about the Kerberos
mailing list