Subject: PKINIT status?

From: "Eric Rosenfeld" <[email-masked]>
Date: Tue, 17 Feb 2004 12:06:21 -0700

Would one of the WG co-chairs please provide an update on PKINIT? We
have been waiting for updated text from the author for quite a while
now. While the author has indicated to me that he will be able to submit
an updated draft by the cutoff (yesterday, I think), there has been no
discussion on this reflector. Given the huge number of updates going
into the latest PKINIT draft, I'd appreciate a status update. I think it
will help everyone understand where PKINIT is, and what the next steps
are.

Thanks,
Eric

Eric S. Rosenfeld
Project Director, PacketCable Security
CableLabs
858 Coal Creek Circle
Louisville, CO  80027-9750

Email: [email-masked]
Phone: 303-661-3841
Fax: 303-661-9199

---

From: Brian Tung <[email-masked]>
Date: Tue, 17 Feb 2004 11:53:02 -0800

> will help everyone understand where PKINIT is, and what the next steps

The draft (pk-init-18.txt) was submitted Sunday evening/Monday morning.
Of the issues previously discussed on the list, I think the following
remain:

    1.  PA and adata types remain to be assigned.

    2.  SubjectAltName syntax: I don't recall if we ever got this right.

    3.  OID for above remains to be assigned, conceivably.

I've seen notice of the draft from the reflector.

Brian Tung <[email-masked]>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 17 Feb 2004 15:00:03 -0500

> will help everyone understand where PKINIT is, and what the next steps

A full PKINIT status update is on the agenda for the upcoming IETF meeting, 
and will appear in the minutes and proceedings from that meeting.  I had 
hoped to wait until that time, to avoid doing this twice, but I can see 
that some people are anxious for some evidence that work has, in fact, been 
going on, so I'll provide a _brief_ update here...

As you know, we reviewed open issues for PKINIT at a side meeting in 
Minneapolis.  A summary of that discussion was presented at the WG meeting, 
and a complete list of open issues was posted to this list in mid-December, 
and again in early January.  Most of the items on that list required only 
that some appropriate person come up with text to address issues on which 
the working group had already reached concensus.  Most of those, in turn, 
were sent directly to the document editor without appearing separately on 
this list.  There's nothing wrong with that -- new decisions weren't made, 
and the working group will be expected to review the complete document.

An updated draft (pkinit-18) was sent to the IETF secretariat over the 
weekend.  It has appeared in the I-D repository and was announced on this 
list.  This update should address nearly all of the items that were listed 
on the open-issues list, plus a few other comments that were raised.  I 
encourage the working group to review this document in detail; unless there 
are significant unforeseen issues, this will probably be the next-to-last 
draft before we send the document to the IESG.

At the moment, I believe the following items are still open issues:

OPEN ISSUES:
?? refactoring preauth [Sam Hartman]
   Sam has indicated that he does not presently have any changes to be
   made to PKINIT to reflect the new preauth framework.  As previously
   agreed, PKINIT will not be held up for the new framework.  So unless
   work on the framework proceeds exceedingly quickly, or PKINIT is held
   up for some unforeseen problem, this item will not result in any
   changes the PKINIT document.

-- specify subjectAltName for user cert
   [tlyu, jaltman, editor; update at ietf58 meeting]
   This work is ongoing, but the details had not been hashed out in
   time for the I-D submission deadline.

-- Confirm alignment with kcrypto [Sasha Medvinsky]
   I've not heard anything specific from Sasha on this, aside from the
   discussion which occurred on this list regarding constructing keys
   from the result of a DH exchange.  It's important that this review
   be done, so that we can be sure PKINIT is using the crypto framework
   correctly.  However, this doesn't have to be an individual effort;
   the working group as a whole is responsible for this document, and
   anyone should feel free to comment on PKINIT-vs-kcrypto issues.

-- Update PA types [Cliff Neuman + editor; last]
   As indicated, this change is deliberately being held until late in
   the process.  As Brian and Cliff work just down the hall from each
   other, I'm sure there will be no problems getting numbers assigned
   for the next (hopefully final) draft.

-- Jeff

---

From: Brian Tung <[email-masked]>
Date: Tue, 17 Feb 2004 12:26:35 -0800

>    time for the I-D submission deadline.

I have the sneaking suspicion that some tentative consensus had been
reached, but unfortunately my notes don't contain it.

>    anyone should feel free to comment on PKINIT-vs-kcrypto issues.

Sasha sent me e-mail that he had done a review and didn't see anything
problematic with respect to crypto.  People may feel free to conduct their
own review, of course.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Feb 2004 15:28:28 -0600

> At the moment, I believe the following items are still open issues:
[...]

One issue that I found (among other more minor comments) when checking
alignment with clarifications seems to have slipped through.

Section 3.2.3 of the PKINIT I-D describes what amounts to cname
canonicalization by the KDC, with the attendant security problems that
were found with earlier [non-PKINIT] cname canon proposals.

I'm not sure that this is really a problem, as I expect that in practice
there will not be more than one certificate to client principal name
association.  Perhaps this should be expressed as a constraint.

Allowing the client to discover the cname of a cert seems to me to be
potentially useful, so I don't want te see this feature go away [yet].
By expressing the above constraint we can keep this feature.

Possible solutions:

 - drop the cname canonicalization feature

 - require that there be no more than one cname per-cert (this is weak,
   from the client's p.o.v.)

 - add a pre-auth type for binding the otherwise unauthenticated
   cleartext in the AS exchange to the key exchange

Cheers,

Nico
--

---

From: Brian Tung <[email-masked]>
Date: Tue, 17 Feb 2004 14:07:44 -0800

>    cleartext in the AS exchange to the key exchange

After talking this over with Nicolas, I think we've identified the right
(or at least *a* right) way to handle this.

Part of the proper text is already in Section 3.2.2:

> If the certificate chain is successfully validated, but the user's
> certificate is not authorized to the client's principal name in the
> AS-REQ (when present), the KDC MUST return an error of type
> KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
> this error.

It remains to move the discussion of the name mapping in Section 3.2.3
over to a name *authorization* discussion in Section 3.2.2.  This will
still rely on a local mapping first, then the SubjectAltName extension
second, but it will not longer suggest that the name is chiefly derived
from the cert--this mapping is for the purposes of authorizing the cert
to the name.

The text above does suggest that the client may omit the cname from the
AS-REQ; is this really right, or should we require the cname to be in
the AS-REQ even when PKINIT is employed?

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Feb 2004 16:00:42 -0600

> were found with earlier [non-PKINIT] cname canon proposals.

Brian points out that the text in section 3.2.3 may simply be unclear or
inconsistent with other text in the same draft.  Ergo there may be
nothing but verbiage to fix here.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Feb 2004 16:17:57 -0600

> the AS-REQ even when PKINIT is employed?

Without extensions and/or a pre-auth-based secure name canonicalization
mechanism the cname field really must be present in AS-REQs.

Nico
--

---

From: Brian Tung <[email-masked]>
Date: Tue, 17 Feb 2004 14:33:09 -0800

> mechanism the cname field really must be present in AS-REQs.

I've already made that assumption and amended the next version of the
draft.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Feb 2004 16:29:52 -0600

> I've already made that assumption and amended the next version of the

Ok.  So no issue then.

Thanks,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Sun, 29 Feb 2004 01:32:35 -0500

>>>>> "Brian" == Brian Tung <[email-masked]> writes:

    Brian> The text above does suggest that the client may omit the
    Brian> cname from the AS-REQ; is this really right, or should we
    Brian> require the cname to be in the AS-REQ even when PKINIT is
    Brian> employed?

My preference to move the document forward faster without having to
carefully consider security considerations of AS requests without
cnames is to require the client to know the mapping.

Now is the time for people to speak up and say this breaks their
planned (or current) deployment.  As I understand Cable Labs, they'll
be OK.