Re: [KAML] Re: Chicago bar-BOF summary

Tom Scavo wrote:
> On 9/6/07, Douglas E. Engert <deengert@anl.gov> wrote:
>> Tom Scavo wrote:
>>> FWIW, we are embedding SAML assertions in short-lived X.509
>>> certificates
>> So you are talking RFC3820 proxy certificates?
> 
> Yes, we have a tool that issues a proxy certificate with a SAML
> assertion bound to a non-critical certificate extension.  We also have
> an online CA that issues short-lived end entity certificates with a
> similar extension.
> 
>> One problem is that PKINIT today does use any of these assertions
>> when issuing a TGT, and does not forward these assertions in the TGT.
>> Thus my suggestion of passing the cert and chain in the TGT.
>>
>> Now if SAML processing is added to the KDC, maybe it should pass
>> along any SAML assertions found in the cert cert chain rather then
>> the full cert.
> 
> Again, just to illustrate our particular use of SAML, the relying
> party traverses the certificate chain up to the first
> non-impersonation proxy (which in practice is usually the EEC) and
> consumes any and all bound SAML assertions.  So multiple assertions
> may be involved, from multiple SAML issuers.

One of my concerns with Kerberos in the middle; who is the relying
party? Is it the KDC or is it the service for which a service ticket

I would argue that in the user's view point it is the service.

Today the KDC has ignored any assertions in the cert (or cert chain
if it supports it at all) and has not passed any of this along to the
service.

There are at least two ways to pass this along:

   (1) Pass the cert and chain, then the service can make its own
       authorization decisions,

   (2) have the KDC find these assertions in the certs and pass them
       along in some new SAML.

   (1) is all but transparent to the KDC, and does not require it
       to understand any SAML or any of the asertions, and does not
       lose any information, in that is is passing on *ALL* the
       information it got including non-SAML information in the certs.

   (2) requires the KDC to parse the certs,and repackage the assertions.
       and it may lose other valuable information in the certs.

    Ticket size might be smaller in (1)the in (2)

KDC are for authentication, they are not expected to do authorization
but may add information to allow the service to do the authorization,
therefore I favor (1) over (2).

> 
> Tom Scavo
> NCSA
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

_______________________________________________
KAML mailing list
KAML@ietf.org
https://www1.ietf.org/mailman/listinfo/kaml