[37267] in Kerberos
Re: Constrained Delegation and PAC : Realm crossover
daemon@ATHENA.MIT.EDU (Rick van Rein)
Tue Oct 20 11:58:59 2015
Message-ID: <562664A8.5010502@openfortress.nl>
Date: Tue, 20 Oct 2015 17:58:32 +0200
From: Rick van Rein <rick@openfortress.nl>
MIME-Version: 1.0
To: Simo Sorce <simo@redhat.com>
In-Reply-To: <56264895.8010803@redhat.com>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
