Null realms and servers

[Nicolas Williams]

On Fri, Dec 15, 2006 at 09:25:46PM -0500, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> 
>     Nicolas> On Fri, Dec 15, 2006 at 06:38:55PM -0500, Sam Hartman
>     Nicolas> wrote:
>     >> First, is it acceptable to release 1.6 in this stae.  My gut
>     >> feeling is that we will need to document the bug, but it is
>     >> acceptable.  It's not great and we want to fix it.
> 
>     Nicolas> IMO, no, it's not acceptable for
>     Nicolas> krb5_sname_to_principal() to return a NULL realm.
> 
> That's nice.  The time for this comment would have been months ago or
> at the latest when the code was introduced.

I just spoke to Sam.

Summary:

 - The change to krb5_sname_to_principal() does not preclude the
   host2realm fallback algorithm that Sun will be pursuing.

 
 - I've convinced Sam that the fallback host2realm algorithm that I
   described, in conjunction with referrals, will be very useful.

   Specifically the algorithm we propose allows zero-configuration
   clients to prosper in any environment that has the following
   characteristics:

    - Realm names correspond to DNS domain names, but without
      necessarily having a sub-realm for every sub-domain.  E.g.,

      .sun.com = SUN.COM
      .east.sun.com = SUN.COM
      .central.sun.com = SUN.COM

    - Hierarchical cross-realm relations are used

      Add referrals and this will work with short-cut trusts also, plus
      minimal KDC-side configuration (domain_realm relations only for
      exceptions).


 - We continue to disagree about whether the MIT change to
   krb5_sname_to_principal() is a backwards-incompatible change.

   However, even if MIT arrived at this change by error MIT is not
   obliged to fix it before releasing 1.6.  MIT may fix it later, in
   1.6.1, if we subsequently agree that this is a backwards-incompatible
   change (and we may not; I am open to being convinced that it isn't).

    - Our difference here is a matter of how conservatively to estimate
      what aspects of the behaviour of krb5_sname_to_principal() form
      part of a stable API and what aspects of it are subject to change.
      
      I believe that resturning a non-NULL, non-empty realm name is part
      of its stable behaviour, whereas Sam does not.

    - In any case, the change will not negatively impact any use of
      krb5_sname_to_principal() in Solaris.


 - Given the fuzzyness of the MIT krb5 API I would like to see a process
   for reviewing potential changes to it.

   And where a conservative view of a fuzzily-defined API is not
   fundamentally incompatible with the feature that would motivate
   changing that API then be conservative.


Nico
--