Re: Federated realms and PAD

On Thu, Feb 16, 2012 at 12:57 PM, Sam Hartman <[email protected]> wrote:
>>>>>> "Nico" == Nico Williams <[email protected]> writes:
>
>    Nico> The biggest problem with what you say Sam is that if it were
>    Nico> correct then it would be an indictment against all existing
>    Nico> multi-mechanism capable GSS-API applications, not just
>    Nico> indictment of Kerberos.
>
> [...]
> I'd like to start with responding to your tone.
> Saying something is an indictment implies there's something wrong.
> I don't think that's true at all.

We've talked about this off-list and I know now that you did not mean
that you took my use of the word "indictment" as a personal slight,
and neither should I take the comment about tone personally either.

For the record, my use of "indictment" was not literal, nor, I think,
out of the ordinary for current English language usage; my use of it
was intended to probe the edges of what you were saying.

Sam and I then talked about what we might want in terms of policy and
GSS APIs.  I'm going to cut to the chase rather than respond line by
line to Sam's message for the sake of brevity as this reply is already
getting too long.

To summarize what's non-federation-like about Kerberos, besides the
items I identified earlier there's also just the fact that without
SAML or something like it with digital signatures we always depend on
the transit realms and the service's realm to vouch for things.  But
this is really just a result of not having digitally signed
authorization-data containers, and there's no reason that we could use
SAML to provide this.

My conclusion is that Kerberos doesn't really have a problem with
federation that couldn't be solved in the same ways that GSS-EAP is
doing.

We also discussed concerns I have with how Sam's GSS-EAP project is
handling policy, namely the fact that there's an implied local policy
that the application does not get to choose or specify, and we
discussed problems that Sam has with our current name attribute model
in the context of Kerberos.

We discussed several different but related things (Sam, please check
that I left nothing out):

 - We already agreed on a need for an "issuer" attribute of names
   and name attributes.  Sam points out that in the absence of
   digital signatures by issuers we end up needing what we
   identified as a concept of "voucher" -- realms that vouch for
   others issuance of various name attributes.

   For example, in Kerberos with the MSFT PAC or the PAD we
   have the service's realm's KDCs vouching for all of the attributes
   in the PAC/PAD, even though those attributes might have
   different issuers (e.g., the client's realm and any transited
   realms).

   The way we would do this is by specifying name attribute names
   that can be used as prefixes for other name attributes.

   To find the issuer of a principal name you'd apply
   GSS_Get_attribute_name() to the NAME and the issuer name
   attribute.  To find the issuer of a name attribute you'd format a
   string as <issuer name attribute name><space><attribute name>
   and get that.

   To find the "voucher" for a NAME or name attribute it'd be the
   same thing, but with the voucher name attribute name.

   Let us call these meta-attributes.  The API is the same as we
   already have in the current I-D (and it already includes the idea
   of composable names).

 - In Sam's GSS-EAP project local policy is applied by the mech
   on the acceptor side, and the application has no choice as to
   policies.

   We both agree that this is not really a good state of affairs.

   Rather than delve into the PGSS idea as a way to specify
   application-specific options I proposed a pair of functions that
   have very simple prototype and semantics and which can very
   quickly be provided even if initially they'd be trivial stubs:

    - GSS_Filter_name()

      This function takes a NAME and a policy name and outputs
      a new NAME (or modifies the input name if no output is
      requested, just like GSS_Add_cred()).  The new/modified
      name may lose some attributes, gain some others, and
      some attributes may have different meta-attributes.

      Inputs:
       - name INTERNAL NAME
       - witness INTERNAL NAME OPTIONAL
       - policy BUFFER OPTIONAL -- system default if not provided
      Outputs:
       - major and minor status, of course
       - output_name INTERNAL NAME OPTIONAL

      The witness argument is for applications like AFS' rxgk,
      where the witness argument would be a NAME of the client
      *host* instead of client *user*.  The witness can be used for
      computing privileges to be granted to the user given the
      client's assertion of local privileges in effect and the server's
      willingness to grant any/some/all of those to certain users
      on certain clients.  E.g., the server can intersect maximums
      for the client and user with the set of privileges asserted in
      the user NAME object.

    - GSS_Authorize_session() (or similar name)

      This function would take just a name and a policy name
      and it would return a boolean indicating whether the
      given principal is allowed access to the application.

      Variants that deal with authorization to operations on
      objects would not be portable, so we'd not specify them.
      Perhaps we could have a GSS_Impersonate_name() that
      sets the current process' execution context to be like what
      the named user's would be -- portable apps could spawn
      a child process to run as the user and perform operations
      on [e.g., filesystem] objects on behalf of the parent process.

 - We talked about how the PAC's netlogon structure and the
   PAD are both attributes and contain attributes.

   For example, each SID in a PAC is effectively an attribute
   on its own.  For domain SIDs the issuer is the corresponding
   domain.  For well-known SIDs the issuer depends on the
   semantics of the given SID.  Either way the voucher is the
   service's realm.

 - We talked about attributes like "full name" that may have an
   issuer/voucher yet not necessarily be produced by either.
   Consider systems where the user is allowed to set their
   full name...  then what is the value of a full name asserted
   by a trusted issuer?  For some attributes we're just bound to
   get sloppy because sloppiness was there all along, and a
   full_name attribute will likely be one of those.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg