Initial Auth Realm Fall-back

[Shawn M Emery]

On 08/20/13 12:01 AM, Shawn M Emery wrote:
> On 08/19/13 09:04 AM, Greg Hudson wrote:
>> On 08/19/2013 02:39 AM, Shawn M Emery wrote:
>>> Wanting to get feed-back on a proposal for initial authentication
>>> through multiple realms when the user may not know which realm or domain
>>> that they reside.  This is key, given that client referrals do not work
>>> unless a UPN suffix is provided.
>> Can you elaborate on this?  Are you talking about Active Directory
>> behavior or client behavior, when you say that AS referrals without UPNs
>> don't work?
> Server side client referrals for AD requires that the client name
> contain a UPN suffix in order to trigger referrals.
>
>>> [libdefaults]
>>>            default_realm = DEV.EXAMPLE.COM
>>>            fallback_realms = CORP.EXAMPLE.COM ACCT.EXAMPLE.COM
>>>
>>> where user foo resides in the ACCT realm and the system has service keys
>>> in the DEV realm.  With this configuration when user foo authenticates
>>> to the system the default realm DEV is tried.  When DEV returns
>>> KDC_ERR_C_PRINCIPAL_UNKNOWN, the new algorithm tries and fails with the
>>> CORP realm request, and succeeds on the third request to the ACCT realm.
>> I can see a couple of concerns off the top of my head:
>>
>> 1. There probably wouldn't be any security guarantees regarding the
>> shadowing of users between realms (possibly with FAST, but only if the
>> implementation were very careful).  An attacker could pretty easily
>> cause a fallback from DEV to ACCT, for a user who actually exists in
>> DEV.  The worst attack I can imagine is getting a client to send an OTP
>> PIN and value to ACCT for a user in DEV or CORP, which may not be a huge
>> deal.
> I believe that customers are aware that user name collisions are evil in
> this type of configuration whether they are using the realm option for
> pam_krb5 or the proposed Kerberos configuration. Inadvertent collisions
> will yield authentication errors where the user's actual realm is not
> first.  For collisions from a compromised realm, yes, there would be
> unintended access for the targeted user(s), but subsequent access to
> services would still require an auth to local mapping for principals
> outside of the service's default realm.

For environments that _do_ happen to have user principal name collisions 
between realms this would not have any more impact on n-strikes for any 
random default realm given that any decrypt integrity error code 
returned would short-circuit the realm fall-back.  As mentioned above, 
the only time the fall-back realm would be used is when the unknown 
principal error code is returned.

>> 2. Getting this to work right with FAST seems tricky.  You would need an
>> armor ticket for each potential realm.  The current command-line
>> interface for FAST kinit (the -T option) wouldn't be adequate.
> In addition, I don't think that this solution would scale very well in
> our customer's environment.

Shawn.
--