Subject: Re: [saag] [Ietf-krb-wg] [pkix] Draft KX509 Proposal

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 20 May 2010 11:22:31 -0500

Stefan Santesson wrote:
> I'm replying to the initial message, having read the whole thread (at least
> the part that has been sent to the PKIX list).
> 
> There are many things with this draft and the discussion which confuses me
> and I would be happy if you could help un-confuse me.

The original kx509 http://www.citi.umich.edu/projects/kerb_pki/ the Readme
file says Kx509 has been around with Kerberos V5 since at least 6/26/2000.
I started working with this in August 1999. It has had wide use but no standards.
Henry is attempting to do this. Thanks Henry.

> 
> Firstly I don't see the relevance of the discussion at large in relation to
> the draft. A lot of things discussed refers to use of name forms, trust
> policies and the potential use of a KCA certificates for PKINIT. Even though
> that is very interesting, I don't see anything in the draft that states that
> a KCA issues certificates for any particular purpose. Strictly reading the
> draft I see a CA that calls itself KCA only based on the fact that it can
> accept this form of request supported by Kerberos authentication.
> 
> If that is true, then the issued certificate could be any type of
> certificate used for any purpose. The Kerberos ticket is then reduced to a
> means of authentication and optionally a source of subject name information
> (Kerberos principal name).
> 

Agreed.

> However, I see nothing that prevents the KCA to map the authenticated
> Kerberos ticket to any other identity data based on a local identity
> database trusted by the KCA.

Agreed.

> 
> If so, then I don't understand why you would limit the lifetime of the
> certificate to the lifetime of the ticket.

Similar to the Windows Auto Enroll certificates, The Kx509 certificates
where originally meant to be short term and disposable where the key is not
protected by a passphrase, but stored in temp protected bu the OS, accessible
only to the user and deleted at logoff. The user could always get another one,
and could have multiple Kx509 certificates one per session and could have them
on multiple machines. Each certificate would have the same subject name derived
from the principal name. Thus a web server would accept these as coming from
the user. Since they are short term, the KCA may not produce CRLs.

> Compare if I use an ID-card to
> authenticate my identity to the passport issuance service, that does not
> mean that my passport will be limited to the validity of my id-card. The
> only thing is that my ID-card is valid when it is used.
> 
> I don't understand why we need to invent a new certificate request format.
> PKIX have already gone through the pain to develop certificate request
> formats that are widely deployed. An obvious flaw in the current draft is
> the lack of proof-of-possession of the corresponding private key, which
> would be avoided if an existing request format was used

The draft is attempting to document the current protocol. I agree that
any new version should use PKIX request forms.

> 
> Maybe small issue. The protocol has no wait message. It only delivers either
> a certificate or an error. What if the request is pending for some reason?

The original KCA would issue or not issue a certificate. There was no way
to hold a request. But in a new version, maybe that would be a good idea,
especially if you want to issue longer term certificates.

> 
> Finally I don't understand why you need to limit the protocol to UDP, or
> even why you need to specify the use of UDP in the first place.
> 

Again that was how the original code worked. The Kerberos tickets and
certificates were small, so UDP worked well. If the next version adds larger
tickets, certificate chains some other  protocol might be better.

> 
> /Stefan
> 
> 
> 
> 
> On 10-05-14 3:32 AM, "Henry B. Hotz" <[email-masked]> wrote:
> 
>> I have just submitted the KX509 draft which I discussed in the Kerberos
>> working group in Anaheim.  It's available at
>> https://datatracker.ietf.org/doc/draft-hotz-kx509/.
>>
>> The immediate question is where (if anywhere) should work on this draft take
>> place.  Since it's function is to translate Kerberos tickets into X.509
>> certificates, it might equally be handled by the krb-wg, or pkix.  Since I
>> understand it's outside the precise charter of both, perhaps saag should step
>> in.
>>
>> What interest is there in handling work on this?
>>
>> ------------------------------------------------------
>> The opinions expressed in this message are mine,
>> not those of Caltech, JPL, NASA, or the US Government.
>> [email-masked], or [email-masked]
>>
>>
>>
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
> 
> 
> _______________________________________________
> ietf-krb-wg mailing list
> [email-masked]
> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
> 
> 

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 20 May 2010 23:47:21 +0200

Thanks for the explanations Douglas.

That certainty brings a lot of clarity. If this is documenting an existing
protocol, then that should be clearly stated. Perhaps it is and I just
missed it?

> the user. Since they are short term, the KCA may not produce CRLs.

This to me is not an argument why this need to be a general rule. This is
just explaining one out of many possible use cases.
Microsoft auto-enrollment is not limited to short lived certificates. It is
equally useful for managing issuance and renewal of long lived certificates.

If the specification doesn't limit the scope of issued certificates, then I
don't think it is appropriate to limit the validity either. The appropriate
lifetime of a certificate is much more dependent on the protection of the
private key and the stability of identification attributes, than it is
dependent on the quality of authentication. That aspect does not degrade
over time. IT either was, or was not good enough at the time of issuance.

/Stefan

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 20 May 2010 22:15:02 -0700

What Doug said.  ;-)

> and I would be happy if you could help un-confuse me.

I think a lot of the comments are from people who already have some familiarity with the protocol.

> accept this form of request supported by Kerberos authentication.

While there are serious issues to point out in the security considerations section, that's fundamentally true.  Nothing is technically out of scope or explicitly prohibited (or impossible even if it were prohibited).  Like everything else, you can shoot yourself in the foot, hand, head, or anywhere else if you so choose.

> (Kerberos principal name).

I wouldn't deploy something that didn't include part of the Kerberos principal name in the cert's Subject name.  I could imagine someone wanting to use a KCA to provide a kind of anonymous authentication though.

> database trusted by the KCA.

Correct, though as a practical matter a UDP protocol with a fixed timeout doesn't work well when the reply is dependent on other services' replies.  Kerberos services typically have shorter timeouts than LDAP services for instance.

> certificate to the lifetime of the ticket. Compare if I use an ID-card to

If the expiration of your ID card actually represents an expiration of the identity it represents, then it would be foolish to issue a passport with a later expiration date.  What you describe is done because the date is usually the expiration of some authorization (e.g. to drive a car) rather than of the identity itself.  An expired passport is still valid as identification (I just used a 2-year-expired one to get a new passport).  It just doesn't authorize you to travel.

If you replicate the original expiration time, then that's "safe" from a policy standpoint.  It's also short enough you probably don't need an OCSP server, etc.  If you want to extend the lifetime, then you should know why your particular infrastructure makes that reasonable.

> would be avoided if an existing request format was used.

I think that's a perfectly valid criticism, which may be addressed in a future revision of the protocol.  In the mean time we have what's already out in the wild.

> a certificate or an error. What if the request is pending for some reason?

I think that's a perfectly. . . (see above)

As noted in Appendix B, I don't fully specify timeout/retry behavior.  I confess the concept of a "wait" response is foreign to me.  Could you elaborate?

> even why you need to specify the use of UDP in the first place.

I think that's a perfectly. . . (see above)

If I don't specify *some* transport mechanism then I haven't specified enough for someone to build an interoperable implementation.

> /Stefan

As Doug noted, this protocol is actually fairly old.  It was originally implemented and documented with Kerberos 4, for instance.

---

From: "Henry B.Hotz" <[email-masked]>
Date: Thu, 20 May 2010 22:35:33 -0700

What Doug said.  ;-)

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 21 May 2010 12:26:11 +0200

In line;

On 10-05-21 7:15 AM, "Henry B. Hotz" <[email-masked]> wrote:

> While there are serious issues to point out in the security considerations
> section, that's fundamentally true.  Nothing is technically out of scope or
> explicitly prohibited (or impossible even if it were prohibited).  Like
> everything else, you can shoot yourself in the foot, hand, head, or anywhere
> else if you so choose.
> 
> I wouldn't deploy something that didn't include part of the Kerberos principal
> name in the cert's Subject name.  I could imagine someone wanting to use a KCA
> to provide a kind of anonymous authentication though.
> 
> Correct, though as a practical matter a UDP protocol with a fixed timeout
> doesn't work well when the reply is dependent on other services' replies.
> Kerberos services typically have shorter timeouts than LDAP services for
> instance.
> 
> If the expiration of your ID card actually represents an expiration of the
> identity it represents, then it would be foolish to issue a passport with a
> later expiration date.

Exactly. And since the it is not clear from the draft that the certificate
will carry an identity that expires at the same time as the ticket, I don't
see why the general rule is that the certificate should not survive past the
ticket used for user authentication.

> What you describe is done because the date is usually
> the expiration of some authorization (e.g. to drive a car) rather than of the
> identity itself.

No. The expiry date of my drivers license is not a date when my license to
drive expires. It is just a date when I have to renew the license, probably
so that I can include a more recent photo and prevent it from falling apart.

>  An expired passport is still valid as identification (I just
> used a 2-year-expired one to get a new passport).  It just doesn't authorize
> you to travel.
> 
> If you replicate the original expiration time, then that's "safe" from a
> policy standpoint.  It's also short enough you probably don't need an OCSP
> server, etc.  If you want to extend the lifetime, then you should know why
> your particular infrastructure makes that reasonable.
> 
> I think that's a perfectly valid criticism, which may be addressed in a future
> revision of the protocol.  In the mean time we have what's already out in the
> wild.
> 
> As noted in Appendix B, I don't fully specify timeout/retry behavior.  I
> confess the concept of a "wait" response is foreign to me.  Could you
> elaborate?

If for example the request is pending. E.g. Because the KCA is waiting for a
response from user identity repository to retrieve user identity attributes
that are going into the certificate, then it would be useful if the KCA
could say like: "Certificate request is pending, ask again later", or "....
Ask again in xx seconds" or whatever is relevant for this case.

> If I don't specify *some* transport mechanism then I haven't specified enough
> for someone to build an interoperable implementation.
> 

Many request/response protocols are agnostic about transport, and other
defines transport in an independent document to make it easy to define how
to add/use other transport protocols over time.

For example RFC 5272 (CMC) and RFC 5273 (CMC Transport protocols)

/Stefan

>> /Stefan
> 
> As Doug noted, this protocol is actually fairly old.  It was originally
> implemented and documented with Kerberos 4, for instance.
>