[ggf-ogsa-sec-wg] Re: [security-wg] bridging of Kerberos realms

[Frank Siebenlist <franks@mcs.anl.gov>]

At 11:16 AM 10/18/2002, Douglas E. Engert wrote:
>You will still need to map that generatede principal to an identity
>eventially, like in the grid-map file, or password file. You might
>get along with adding the certificate chain to a PA-data field in the
>Kerberos ticket.


Understood.

My goal was to identify potential user databases and mapping tables that 
would either be redundant or unnecessary in some deployment scenarios.

So, if you have two authentication-id's: a kerberos principal name and a 
PK-DN, and you have one access-id that is used in the authorization policy 
rules, then you would need mappings for both the principal and DN to the 
access-id.

If you would also be able to obtain a kerberos TGT with your PK credential, 
there shouldn't be a need for a DN to principal mapping table.

Or, if you have access to the resources only through kerberos, and you have 
a public key credential that is acceptable for authentication, then you 
shouldn't need a separate principal name.

My experience is that most sysadmins agree that it is better to have fewer 
user databases and mapping tables than more ;-)


-Frank.





Frank Siebenlist wrote:
> >
> > At 08:06 AM 10/3/2002, Moore, Patrick wrote:
> > >[...
> > >For getting Kerberos creds into services that get, at
> > >most, a delegated X509 proxy cert, that's a bit harder.
> > >Doug Engert has a solution that uses a GSI-aware KDC.
> > >Another solution might be a generalized OCR (myProxy)
> > >that acts as a K5 TGT user cred repository, supports
> > >GSS/K5 ticket authentication (middle tier would
> > >typically use a keytab to authenticate to the OCR.)
> > >This OCR could make 'where-to-delegate' decisions base
> > >on a combination of the middle tier's keytab identity
> > >plus perhaps its posession of a GSI proxy cert for the
> > >user. Might be stronger than what we do today with
> > >delegated K5 creds, and might provide very useful
> > >features for supporting very long running jobs/workflows.
> > >But that's a far-off vision, and I'm not sure how well
> > >it could be sold to the ASCI security people.
> >
> > I just wanted to point out that Doug's GSI-aware KDC or a possible
> > gsi-aware pkinit implementation still have to do the mapping of a DN to a
> > principal name and that there is a need to maintain that principal 
> database.
> >
> > Why not go one step further and generate the principal names on the fly by
> > deriving them from the authentication-id, i.e. DN or public key?
> >
> > There seems no real need for a principal database if you are already using
> > an other mechanism to authenticate.
> >
> > It would be a very lightweight KDC that you can drop into deployments that
> > require kerberos protocols for authentication, but where the primary
> > authentication may be PK.
> >
> > -Frank.
>
>--
>
>  Douglas E. Engert  <DEEngert@anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444