Ken Hornstein wrote:

> This is going to be my last message on this topic, honest.
> 
> - Clearly neither of the two open-source Kerberos implementations consider
>   this a security problem, as they do not perform this checking.  If it
>   was a "nasty security problem", we'd see CERT warnings issued and patches
>   to correct the problem.
> 
> - This could only conceivably be an issue if you allow users to create
>   arbitrary principal names.  I know that CMU allows users to create
>   arbitrary instances for some strange reason, but even you have to
>   admit that this is a rather uncommon practice.  For sites that don't
>   allow users to create arbitrary principals, the only thing this check
>   accomplishes is that it breaks things for V5 sites that have created
>   principals with "." in their names (it doesn't even do a mapping to
>   something else; it just silently rejects them!)
> 
> --Ken

The MIT krb524d code will perform the following translations:

v5:  [user] [admin]  (two components) ->   v4: [user] [admin]
v5:  [user.admin]    (one component)  ->   v4: [user.admin]
v5:  [user/admin]    (one component)  ->   v4: [user/admin]

The problem we have is really not what krb524d is doing because krb524d
provides for the ability to distinguish between a single component name
and a multi-component name.   Kerberos 5 does not convert a
multi-component name to a single component name.

The place where there is an issue in within AFS because we do not have
the ability within AFS to distinguish between v4 [user.admin] and [user]
[admin] after we translate the principal name to a string.

The problem simply becomes of greater concern due to the fact that
in v4 there are a maximum of two components (name and instance) that
are separated by a "." for display purposes.   This makes it more likely
in Kerberos 5 that someone will create a single component principal name
that contains a "." since in Kerberos 5 the "." is not a special
character for display purposes.

I believe this is a concern but it is not a concern at the Kerberos
layer.  It is a concern only within AFS.

Jeffrey Altman

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to