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