Subject: pkinit issues

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Aug 2004 14:33:35 -0700

I have spent some time collecting the complete state of some 40 issues
with PKINIT since Boulder, about half of which are resolved.  I have
assigned to each issue one of four states:

  DONE - resolved; no further work required
  OPEN - work is still required on this
  NEW  - this item is new with this post
  XXXX - I'm not sure whether this is resolved.

For the issues that are not DONE, I've summarized the current state
and broken them down into major, minor, and editorial issues.  All
of the major and minor issues will be touched on during this week's
working group meeting.

At the end, I have attached the list of all issues, both open and closed,
and my complete notes on the discussion of each of these issues.  I hope
to have imported all of these issues into RT by the end of the week.

-- Jeff

======================================================================

First, the few major open issues which still require significant work
or are controversial.

*OPEN* 013 - OCSP and optional revocation information
  It seems to me that we have agreement that support for OCSP is a
  valuable feature.  We also seem to have converged on a single
  specification which includes the best parts of Nico's and Larry's
  proposals.  AT this week's WG meeting, we will discuss whether to
  incorporate this text into PKINIT or leave it as a separate
  document.

*OPEN* 017 - DH key derivation
  This is the subject of what that Sam and Larry are currently
  working on.  We'll hear about the status of this at the meeting.

*OPEN* 031 - Which encoding - DER vs BER? (Love #2)
*OPEN* 035 - Wrap CMS objects in octet-strings?
  These are related, and still under discussion.  It is my opinion that
  we seem to have support for wrapping all CMS objects in OCTET-STRING's.
  I think we need a volunteer to write this text.

  I also want to hear from folks who have already tried implementing
  PKINIT, on two issues:
  (a) Does wrapping objects in OCTET-STRING's actually make it easier
      to implement PKINIT using off-the-shelf CMS libraries?
  (b) While this approach doesn't change the semantics of PKINIT,
      it is a nontrivial change to the wire protocol.  Is this going
      to cause problems for implementors?

======================================================================

This next group of issues are questions which need to be resolved by
the working group before this work can be considered complete.

*OPEN* 020 - Unauthenticated plaintext issues
  This issue seems to have been dropped on the floor.  We need a
  resolution on this before the document can move forward.

*OPEN* 028 - Nonce type?
  This was opened back in February, and there was never any response.

*XXXX* 030 - What key should the reply be enveloped with in the
             encKey case? (Love #1)
  I don't see this addressed in discussion on the mailing list.

*OPEN* 034 - subjectAltName/OtherName issues (Love #7)
  I've seen no discussion addressing this item, either.

*NEW* 038 - DH groups selection
  Both Love and I noticed that we are recommending use of RFC2409 groups
  1 and 2.  This isn't going to pass muster; we need to recommend one
  of the larger groups from RFC3526

*OPEN* 039 - Root CA cert in chain?
  Jeff, Sam, and Martin have discussed this at length, but I don't see
  a resolution.  We need conclusion on this question and appropriate
  text.

*OPEN* 040 - encryption certificate change not protected
  Love brought this up in the last couple of days.

======================================================================

The remaining issues are mostly either editorial changes or things
which I suspect are closed but need confirmation on.

*XXXX* 002 - REMOVE use of raw public keys
  It was claimed this was done in -17, but I don't know what this is.

*XXXX* 004 - Security of cached DH values and use of a nonce
  This was an "evaluate and propose" task.  I believe this has been
  completed, and the output is what lead to the current DH work.
  Can someone confirm this?

*XXXX* 005 - Confirm alignment with CMS
  Another "evaluate and propose" task.  Again, can someone confirm
  that this was actually done?

*OPEN* 007 - Confirm alignment with kerberos-clarifications
  Some minor editorial issues need to be cleaned up to close this.

*OPEN* 009 - Update PA types
  Still deferred until the last minute.

*OPEN* 021 - TrustedCAs context tags broken (Love #5)
  Another editorial item.  This was half-fixed, and needs to be
  fixed the rest of the way.

*OPEN* 024 - cname mapping proposal
  I believe this was actually a spinoff of #023, and was resolved
  in the same way.  I'd like confirmation from Larry to that effect.

*OPEN* 026 - Unconstrained Integers (Love #6)
  There are still two uses of unconstrained INTEGER types.

*NEW* 037 - ASN.1 module inconsistency
  The module appendix is good, but not perfect.  It needs to be fixed.

======================================================================

===========================================================================
===
*DONE* 001 - Negotation of CMS encryption types

>>> Sep, 2003 interim meeting <[email-masked]>

Ken Raeburn: My concerns are regarding the overloading of the negotiation
of the encryption negotiation for PKINIT.  If public key negotiation
uses a Kerberos enctype number, do they need a full KCRYPTO specification?
That would seem sub optimal, since many parts of the KCRYPTO specification
are not applicable to CMS algorithms used in PKINIT (like string-to-key).

After an extensive discussion, it was agreed that a new optional field shall
be added to the PKINIT messages from client to server (somewhere is
PA-PK-AS-REP) with the new CMS encryption types.

XXX ACTION ITEM to design change

>>> 24 Nov 2003 <[email-masked]>

Love:
should enctype be added for acceptance of id-aes128-CBC, id-aes256-CBC
(rfc3565) as part of EncryptedContentInfo for CMS messsages ?

>>> 6 May 2004 <[email-masked]>

Ken Raeburn:
Section 3.1.x last paragraph, last sentence would seem to indicate that any 
new
encryption system to be used with the PK bits must get a new Kerberos
cryptosystem number assigned.  Weren't the existing numbers going to be used
only for backwards compatibility, and new encryption systems listed only by
OID?  (Sorry, I've been a bit preoccupied with some other work and non-work
activities, and haven't followed the PKINIT discussions much lately.)

Love:
Yes, it should be oid and not kcrypto numbers since they are CMS
types. This apparently been discussioned already, its just noone that have
send text to Brian. Here is proposal to text:

    AuthPack ::= SEQUENCE {
        pkAuthenticator         [0] PKAuthenticator,
        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
        supportedCmsTypes       [2] SEQUENCE OF AlgorithmIdentifier
        ...
    }

[...]
supportedCmsTypes are those CMS types that are supported by the client CMS
system.
Love: supportedCmsTypes should be OPTIONAL
And this text should be added:

"
If the KDC doesn't support any of the CMS types that the client supports it
should return KRB5KDC_ERR_ETYPE_NOSUPP.
"

The error code could be replaced by another equally confusing error code.

Should the supportedCmsTypes be ordered in preference of the client ?

Should it be a SEQ of OBJECT IDENTIFIER or some more like SMIMECapabilities
(that AlgorithmIdentifier is, but I not sure we should overload it).

RESOLVED - supportedCmsTypes and related text added in -20

===========================================================================
===
*XXXX* 002 - REMOVE use of raw public keys

>>> Sep, 2003 interim meeting <[email-masked]>

ACTION ITEM - editor - update draft to remove use of raw public keys

XXX This was probably fixed in -17, and the old issues list indicates
it is closed, but I am unable to tell what this referred to.

===========================================================================
===
*DONE* 003 - REMOVE X.500 Name Transformation

>>> Sep, 2003 interim meeting <[email-masked]>

ACTION ITEM - editor - update draft to remove X.500 name transformation

RESOLVED - X500-RFC2253 and related text removed in -17

===========================================================================
===
*XXXX* 004 - Security of cached DH values and use of a nonce

>>> Sep, 2003 interim meeting <[email-masked]>

Todd Stecher volunteered to issue regarding the handling the security of
the cached DH values...

ACTION ITEM - Microsoft - evaluate cached DH values and propose changes

XXX old issues list indicates this was closed

===========================================================================
===
*XXXX* 005 - Confirm alignment with CMS

>>> Sep, 2003 interim meeting <[email-masked]>

ACTION ITEM - Microsoft - evaluate CMS alignment and propose changes

XXX old issues list indicates this was closed

===========================================================================
===
*DONE* 006 - Confirm alignment with kcrypto

>>> Sep, 2003 interim meeting <[email-masked]>

ACTION ITEM - smedvinsky - evaluate kcrypto alignment and propose changes

>>> 23 Oct 2003 <D5A7E45D575DD61180130002A5DB377C0766EFE9@ca25exm01>

Sasha Medvinsky proposed the following:

In addition to these proposed changes to the PKINIT draft, PacketCable
implementations currently use DES3-CBC-MD5 etype that was at one time 
defined
in the Kerberos revisions draft (although the definition was not fully
specified).  Since the crypto draft already contains legacy etypes and 
checksum
types that use identity function for key derivation, is it possible to add 
back
in the DES3-CBC-MD5 etype with maybe language that it is a legacy crypto 
system
and a strong recommendation to use the 3DES etype with key derivation?  The
same question applies to the RSA-MD5-DES3 checksum type that at one time was
defined in Kerberos revisions.

Ken Raeburn replies:

I'd rather not add more cryptosystems to the document, unless we're
going to be promoting their use in general implementations.  RC4 isn't
going in, either, and it's probably closer to having a complete
specification.  Adding more to the crypto draft would pull it back to
the working group, delay its publication further, and delay the
documents depending on it.  There's no reason they can't be published
in separate documents.

RESOLVED - The DES3-CBC-MD5 enctype is _not_ defined in kcrypto.

===========================================================================
===
*OPEN* 007 - Confirm alignment with kerberos-clarifications

>>> Sep, 2003 interim meeting <[email-masked]>

Nico Williams brought up the following clarifications alignment issues:

- Use of unconstrained integer
- Cut & pasting of typed data
- References to RFC1510 & RFC1510bis

And he volunteered to work on them.

ACTION ITEM - nico - evaluate clarifications alignment and propose text

>>> 6 May 2004 <[email-masked]>

Ken Raeburn:
Should preauth systems in general be adding to the Kerberos error code list?
Or should we have a way of attaching a tuple of { preauth system id,
preauth-system-specific error code } to an error reply?

DEFERRED unconstrained integer to ticket 026
FIXED - typed-data is now IMPORTed from kerberos instead of cut/paste
NOT YET RESOLVED - two references to "RFC 1510bis" appear in pkinit-20

===========================================================================
===
*DONE* 008 - Internationalization of strings

>>> Sep, 2003 interim meeting <[email-masked]>

ACTION ITEM - jaltman - evaluate internationalization and propose text

>>> 9 Nov 2003 <[email-masked]>

1. Remove Reference to:

    [11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
    Protocol (v3): UTF-8 String Representation of Distinguished Names.
    Request for Comments 2253.

The only potential internationalization issue is the representation of the
PrincipalName to which the certificate is mapped.  Valid PrincipalNames are
those belonging to the version of Kerberos being used.  If the Kerberos
implementation is [@CLARIFICATIONS] then the names are limited to US-ASCII.
If a future Kerberos implementation is used, then whatever Principal names
are valid for that implementation may be used by PK-INIT.

There are two places where PrincipalNames are specified in PK-INIT, the
requested PrincipalName and the principal name specified in a certificate
by the use of a subjectAltName extension.
The requested PrincipalName is the name specified in the AS-REQ.  The
ability to use internationalized strings is dependent entirely on the 
version
of Kerberos being used.  If the version of Kerberos being used provides
for internationalized strings, then the rules associated with that version
of Kerberos protocol must be adhered to.

The subjectAltName extension supports the inclusion of Unicode utilizing
unnormalized UTF-8 encoded strings.  These strings must be processed by
the receiving KDC and string prepared according to the rules for query
strings if any are specified.  In the case of [@CLARIFICATIONS] there are
no rules specified, however, any string which is not restricted to US-ASCII
will fail to match a valid PrincipalName.

ACTION ITEM - editor - remove reference to RFC2253 (UTF-8)

RESOLVED - reference removed in pkinit-17

===========================================================================
===
*OPEN* 009 - Update PA types

>>> Sep, 2003 interim meeting <[email-masked]>

The protocol described by the current document is not compatible with
that deployed under the existing PA-DATA type numbers.  Thus, new numbers
must be assigned to identify the new protocol.  This should be done as
late as possible before the new document is sent to the IESG.

ACTION ITEM - bcn - assign new PA-DATA type numbers
ACTION ITEM - editor - update draft to reflect new PA-DATA type numbers

===========================================================================
===
*DONE* 010 - Refactoring Kerberos Preauthentication

>>> Sep, 2003 interim meeting <[email-masked]>

PKINIT is needed by some vendors, if the Preauth framework is not
complete by November, the PKINIT should proceed on its own.

ACTION ITEM - hartmans - propose any needed text for preauth refactoring

RESOLVED - preauth refactoring will not proceed quickly enough to bring
PKINIT to conclusion in a timely manner, despite the delays on PKINIT work.

===========================================================================
===
*DONE* 011 - Transited-realm field

>>> Sep, 2003 interim meeting <[email-masked]>

Nico Williams proposed that there was no reason that CAs should appear
in the transited realms field, since they weren't realms.  An extensive
discussion ensued.  The suggestion came up that transited CAs would
appear in a new authorization data field.  It was finally reached
that the authorization data should be added with the semantics that if
you do PKINIT with a non zero list of CAs, you MUST include the
authorization data field.  Nico Williams volunteered to come up with
an A-D type, the semantics for it, and possibly text to go into
PKINIT.

ACTION ITEM - nico - design new A-D type and submit text

AD-INITIAL-VERIFIED-CAS appeared in -19

>>> 30 Mar 2004 
<[email-masked]>

Eric Rosenfeld:
3) There is no need to make the AD-INITIAL-VERIFIED-CAS data type (and
the InitialVerifiedCAs ASN.1 object) a MUST. This was an issue that I
objected to at the interim meeting, but shelved my objections in order
to make progress at the meeting. The proposed text has confirmed my
original concern. I would really like to see this data type be made
optional.

>>> 21 Apr 2004 
<[email-masked]>

Eric Rosenfeld:
So I guess is what I'm saying is that I'll drop my objections if someone
can explain to me what the fundamental security flaw is, and why
mandatory inclusion of this field (even if it is empty) addresses that
security flaw.

>>> 26 May 2004 
<[email-masked]>

Eric Rosenfeld:
I'm back. Looks like there has been a lot of discussion on PKINIT,
although there still seem to be a bunch of open issues. In an effort to
close at least one issue, you can remove my objection to the
AD-INITIAL-VERIFIED-CAs field. While I still don't feel that it is
necessary, it seems like several WG members feel it serves the same
purpose as the mandatory transited-realms field. Given the desire to
remain consistent with previous WG decisions, let's just close this
issue and require the field.

>>> 12 Jul 2004 <[email-masked]>
Brian Tung, speaking also for Sasha and Eric:
2.  We propose to include the AD-INITIAL-VERIFIED-CAs structure into the
    PKINIT specification.  There seems to be some confusion about whether
    it is permissible for this structure to be empty--that is, for it to
    contain no CAs at all.  We don't believe that there is a significant
    problem with it being blank, and it seems to be part of the original
    intent of Nico's specification to permit it to be empty.

    One potential issue with an empty field is that it takes away the
    application server's ability to make authorization decisions based
    on the content of the CA list.  That server is then placed in the
    unusual situation of trusting the KDC's packaging of the ticket,
    but not on its verification of the user's certificate chain.  We
    don't think this necessarily leads to a security hole, provided that
    these implications are carefully explained; decisions on whether to
    allow the CA list to be empty (and, for the application server, on
    whether to authorize service based on an empty CA list) can then be
    relegated to local policy.

Sam Hartman:
It does lead to a difference between how pkinit works and how the rest
of Kerberos works.  I do not believe that this inconsistency serves
the Kerberos community.

[ERIC] I seem to remember a different proposal. I don't recall
restricting the empty field to only the case where no CAs were used. I
do recall allowing it to be blank, based on KDC policy.

RESOLVED? - pkinit-20 includes nico's text; eric withdraws objections

Sam Hartman:
2) The ad-initial-verified-cas text has not been updated even though
    we had a fairly strong consensus that it was under specified
    currently.  Nico was going to supply text for this.

===========================================================================
===
*DONE* 012 - Use of principal name in trusted-cas

>>> Sep, 2003 interim meeting <[email-masked]>

Nico Williams (Sun) pointed out that the use of the principal name in the
trusted-CAs field might be an artifact of the use of a raw public key, and
since that is being removed, perhaps it should be removed.  The consensus
of the group was that this should be removed.

ACTION ITEM - editor - update draft to remove principal from trusted-cas

>>> 9 Nov 2003 <[email-masked]>

Jeff Altman mentioned this issue again

RESOLVED - fixed in pkinit-17

===========================================================================
===
*OPEN* 013 - OCSP and optional revocation information

>>> Sep, 2003 interim meeting <[email-masked]>

Todd Stecher volunteered ...  to provide a proposal for the use of OCSP.

Todd provided an overview of the OCSP issues: basically, data is needed
in the AS_REQ and the AS_REP to provide the OCSP signed data (OCSP protocol
issues are "sketchy" at this point).

ACTION ITEM - Microsoft - generate an OCSP proposal

>>>  Feb 2004 <[email-masked]>
Love:
I can't match what the author of this section match to RFC2560.  For
example, ResponderID is part of the ocsp response not the request. And its
the OCSP responders id, why should a client ask for that ?

And before I read rfc2560, thinking that this text simply should be dropped.

"The changes proposed
in this section allow a client to request an OCSP response from the
KDC when using PKINIT."

What document is sited here ?
 "This is similar to the way that OCSP is handled in [cite]."

Reading rfc2560, I can only say that PA-PK-OCSP-RE{Q,P} should look like
below

"The KDC MAY refuse to relay requests for certificate(s) that isn't for it
own certificate, or any of it peer KDCs certificates, or any certificates
in the chain."

PA-PK-OCSP-REQ ::= SEQUENCE
        request         [0] OCSPRequest,
        ...
}

PA-PK-OCSP-REP ::= SEQUENCE
        response        [0] OCSPResponse,
        ...
}

>>> 30 Mar 2004 
<[email-masked]>

1) OCSP - The latest draft defines a tunneling mechanism for OCSP. OCSP
could be used in different ways, so the use of OCSP really should be
separate from OCSP, especially a tunneling mechanism as defined in the
draft. We are concerned that brand new functionality is being added to a
draft that we are trying to move to last call. OCSP support was not
agreed upon at the interim meeting (it was only decided that Microsoft
would provide OCSP feedback), and certainly a tunneling mechanism was
not discussed. It seems like the right way to approach this issue would
be to remove OCSP from PKINIT, and turn it into a separate draft.

Nico: Support moving to a separate draft
Jeff Altman: Support

JK:
The OCSP tunneling logically belongs in the PKINIT draft. I haven't heard 
any
clear arguments for moving it to another draft other than 'it can be done'. 
I
don't see how it would hold up the PKINIT draft in anyway. What are the 
major
technical objections here? The same work has already been done for TLS so we
are not doing something that is a major addition.
I very much doubt the OCSP work would be standardized if we had to go 
through a
whole separate draft process.

Nico: Not required; can be moved; should move if it would delay PKINIT

Sam Hartman: If the WG believes it is important and will only get done if
bound to PKINIT, then that is what we should do.

Doug Engert: Unless PKINIT would not be useful without OCSP, it should move 
out

>>> 22 Jun 2004 
<[email-masked]
ev.microsoft.com>

JK: We (MS) believe it is appropriate to retain OCSP tunnelling in PKINIT
Eric: Strongly object
Sasha: Agree with Eric
Nico: Separate draft
Larry: Don't think it's been established that significant complexity is 
added
Martin: Disagree w/Larry

<Much arguing>

>>> 12 Jul 2004 <[email-masked]>
Brian Tung, speaking also for Sasha and Eric:
1.  We propose to withdraw the OCSP mechanism from PKINIT.  Although it
    has potential benefit, it is not integral to the operation of PKINIT.
    It also represents an additional point of potential delay for
    advancement.

    In the absence of an overriding argument one way or the other, we
    feel that given a choice between including OCSP and not including
    it, it is better to be conservative and withdraw it from the PKINIT
    draft.  We do not believe this strikes a damaging blow to the
    mechanism itself, since there seems to be significant support within
    the working group for laying down a specification for it.  We simply
    think it is better done in a separate draft.

Brian:
However, assuming I stipulate to requiring the OCSP responses, I don't
see that it makes much sense to put it in another draft.  In order to
verify that I am compliant with PKINIT, I should have to check the
PKINIT draft *plus* the OCSP add-on draft?

But I also don't see that supporting this has to be a requirement (for
both sides) for PKINIT compliance.  Can you explain your rationale for
it being a requirement?

<nico posts a draft>
<larry posts text>

XXX there has been much further discussion on OCSP tunnelling, including
XXX work by both Nico and Larry to define mechanisms.  This issue is not
XXX yet resolved, but should be by the WG meeting.

===========================================================================
===
*DONE* 014 - Extensibility

>>> Sep, 2003 interim meeting <[email-masked]>

In terms of extensibility, Jeff Hutzlman suggested that extensibility
can be achieved by adding ASN.1 extension markers in the appropriate place,
and adding typed holes can be done via a protocol revision (if that ever
happens).  Jeff Hutzlman volunteered to handle this.

ACTION ITEM - jhutz - evaluate extensibility and propose changes

RESOLVED - Extension markers appear in all the right places in pkinit-20

===========================================================================
===
*OPEN* 015 - Indicating PKINIT support

>>> Sep, 2003 interim meeting <[email-masked]>

Sam Hartman brought up the point that there's no way for the KDC to indicate
that it does PKINIT, but it was decided that this would be discussed later.

===========================================================================
===
*DONE* 016 - Initial flag disposition

>>> Sep, 2003 interim meeting <[email-masked]>

Cliff Neuman volunteered to handle the initial flag issue.

ACTION ITEM - bcn - resolve initial flag issue

>>> 8 Jan 2004 <[email-masked]>

Concensus is that the flag MUST be set on tickets issued using PKINIT.

ACTION ITEM - editor - update draft to reflect initial flag required

RESOLVED - text appeared in pkinit-18

===========================================================================
===
*OPEN* 017 - DH key derivation

>>> 23 Oct 2003 <D5A7E45D575DD61180130002A5DB377C0766EFE9@ca25exm01>

Sasha Medvinsky proposed the following change:

OLD: truncate DH secret to desired length, and call random-to-key
NEW: If enctype supports KD, use DH secret directly as base key.
     Otherwise as before, truncate and call random-to-key

Ken Raeburn objects -- this would do the wrong thing for e.g. 3DES.
The base key used in KD must be of the correct format; the right way
to do this is to use the random-to-key operation.

Sasha and Joel Weber both point out that accepted practice in other
protocols is to use the entire DH secret, rather than a truncated
part.

Sam points out, correctly, that this issue relates to kcrypto and
if there is a problem, it should be brought up with the IESG as that
draft is already out of the WG.  He also objects to any change which
would introduce a global, non-enctype-specific dependency on a
particular hash, rather than using the properties of the negotiated
enctype.

>>> 24 Nov 2003 <[email-masked]>

Love also expressed concern about this issue.

>>> 10 Dec 2003 <[email-masked]>

Jan Nordqvist asked how to handle this

>>> 23 Jan 2004 <D5A7E45D575DD61180130002A5DB377C0766F306@ca25exm01>

Sasha Medvinsky gave a good summary of the current state.
Still no concensus on this issue.

>>> 9 Apr 2005 
<[email-masked]
ev.microsoft.com>

Larry Zhu:
Simply truncating ZZ probably won't preserve the secret entropy. why
don't you use the key generation algorithms specified in RFC 2631?

If anyone knows of works that study this ephemeral-ephemeral
Diffie-Hellman mode in detail, I would appreciate pointers.

Larry agreed to research this further.

>>> 27 Apr 2004 
<[email-masked]
ev.microsoft.com>

Larry Zhu:
1) DH key agreement: initial conversation with Dan Simon at Microsoft
indicated that the truncation is probably safe. I am not sure if I can
answer Sam's the questions at this point, but one suggestion that Dan
brought up is that why can't we just allow for negotiation and support
of multiple algorithms for the pseudorandom function/MAC calculation?
Sam you won't object to hashing the entire ZZ if we can do it without
depending on a particular checksum algorithm, correct?

>>> 23 Apr 2004 <[email-masked]>

Jonathan Trostle:
DH truncation is should be fine. See the paper "Hardness of Computing the
Most Significant Bits of Secret Keys in Diffie-Hellman and Related Schemes"
by D. Boneh and R. Venkatesan. For example, they show that computing
the 32 MSB of the DH shared secret is as hard as computing the entire
secret, when using a 1024 bit prime (sqrt(p) = 32 bits).

>>> 6 May 2004 <[email-masked]>

Ken Raeburn:
The case where len(seed) < k should be addressed, if only to explicitly
disallow combinations of key type and "p" value where it could happen.  It's
not likely to with existing cryptosystems, but I bet I could invent a
cryptosystem fully compliant with the crypto framework, perhaps based on 
public
key crypto, for which the seed would need to be very large.  (Not a fast 
one,
perhaps, but it doesn't need to be particularly desirable to demonstrate the
existence of a problem.)

I'd suggest ending the paragraph discussing random-to-key with "for example"
and dropping those words from the "1" paragraph following, to make it clear
that both (1) and (2) are examples, not normative specifications.

>>> 1 Jun 2004 
<[email-masked]
ev.microsoft.com>

Larry Zhu:
I would like to explore the options of allowing both the KDC and clients
insert randomness into the exchanged key, thus enabling static-static DH
key exchange. I am writing up a simpler proposal for this (simpler than
the one I sent over a while back), to address the complexity issue. I
shall be able to send it out within the next two weeks or so.

>>> 2 Jun 2004 <[email-masked]>

Sam Hartman:
Please restrict yourself to the operations defined in kcrypto.  We
convinced ourselves that generating a combine keys function was
possible with those operations.  I believe kenh has the notes on this.

Actually, wait, doesn't the existing proposal *require* both sides to
contribute randomness to keys?

Larry:
The highlight of our proposal is to negotiate the supported hash
algorithms and it does so by leveraging the existing enctype negotiation
thus it does not need new fields in the existing PKINIT messages for the
negotiation, and it will only use operations within the framework of
kcrypto.

Can it do so when static-static DH is used? We do not think it would
make sense to require either side to generate the DH domain parameters
more frequently than necessary.

>>> 12 Jul 2004 <[email-masked]>
Brian Tung, speaking also for Sasha and Eric:
3.  We propose that no changes be made to the Diffie-Hellman key
    agreement text in PKINIT.  PKINIT currently refers to the Kerberos
    crypto draft as to how a session key is derived from DH key
    secret are passed into a random-to-key fnction and what that
    random-to-key function is.

    Therefore, whether and how DH key derivation needs to be modified
    should not affect the specification of PKINIT.  If there is a need
    to change the key derivation procedure, this should be done in the
    Kerberos crypto draft, allowing the change to be re-usable outside
    PKINIT.

    Furthermore, until this time there had been no evidence to indicate
    that the currently specified DH key derivation was not sufficiently
    secure.

Sam Hartman:
We seem to have convinced ourselves that the current text is secure.
However it does not allow for DH parameters to be cached.  Microsoft
believes this is an important feature; I agreed to help them specify
it but have not had time to work on text (and will not have this time
before the draft deadline).

===========================================================================
==
*DONE* 018 - DH parameter sizes

>>> 23 Apr 2004 <[email-masked]>

Jonathan Trostle:
I can't find any recommendations for sizes of DH parameters in the current
version of the draft. Generally the DH exponent should be twice as many
bits as the resulting shared secret key, e.g. using a 200 bit exponent
corresponds to a 100 bit shared secret. There should be a statement
on this.

Sam Hartman: refer to the IETF's BCP on this issue

RESOLVED - BCP86 discusses this issue in detail

===========================================================================
===
*DONE* 019 - DH key derivation with cached parameters

>>> 23 Oct 2003 <D5A7E45D575DD61180130002A5DB377C0766EFE9@ca25exm01>

Sasha Medvinsky proposed the following change:

Section 3.2.1
-------------------
OLD TEXT that is to be deleted:
    If cached parameters are used, the client and the KDC MUST perform
    key derivation (for the appropriate cryptosystem) on the
    resulting encryption key, as specified in RFC 1510bis.

RESOLVED - text removed in pkinit-17

===========================================================================
===
*OPEN* 020 - Unauthenticated plaintext issues

>>> 8 Nov 2003 [email-masked]>

Sam Hartman:
I would appreciate help with one issue I'm running into.  It seems to
me that the pkinit reply does not actually sign anything in the KDC
reply.  Is this true?  You end up getting a signed copy of the reply
key, but not really any verification of the other parts of the
request.

It seems like we should look at what unauthenticated plaintext issues
pkinit has.  I don't think I can see any particular protocol flaws,
but it does seem like the security considerations section needs to be
expanded to address these issues.

Brian Tung:
It seems to me that it's unlikely to cause any protocol flaws, since
anything that's unauthenticated in PKINIT would have to be unauthenticated
in ordinary Kerberos, too.  Do you think there's any low-lying fruit to
be gathered by signing the reply in addition to the reply key?

no further replies seen

NOT YET RESOLVED

===========================================================================
===
*OPEN* 021 - TrustedCAs context tags broken (Love #5)

>>> 24 Nov 2003 <[email-masked]>

Love:
Why was fields reorderd/tag changed in TrustedCas ? Couldn't it just have
dropped.

>>> 17 Feb 2004 <[email-masked]>

Love: still broken in -18
Brian: fixed in next version

>>> 31 Jul 2004

As of pkinit-20, this is still broken:
  pkinit-16: principalName[0], caName[1], issuerAndSerial[2]
  pkinit-17: caName[0], issuerAndSerial[1]
  pkinit-20: caName[0], issuerAndSerial[2]

The context tag on issuerAndSerial was fixed, but caName is still wrong.

===========================================================================
===
*DONE* 022 - Specify subjectAltName for user cert

No clue what this is.  It first appeared in my status update after the
Minneapolis status meeting.

>>> 30 Mar 2004 
<[email-masked]>

Eric Rosenfeld:
        - Definition of subjectAltName was incorrect. It used
OTHER-NAME, which was in RFC2459, but defined differently in RFC3280
because of incompatibilities between 93 syntax and 88 syntax. We had to
perform major surgery here.

RESOLVED - Text is correct as of pkinit-19

===========================================================================
===
*DONE* 023 - Client name canonicalization problems

>>> 17 Feb 2004 <[email-masked]>

Nico:
  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

Brian:
  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?

After further discussion, concensus seems to be that the cname field
in the AS-REQ should be required even when PK-INIT is used.  All of
Nico, Sam, Brian, Eric spoke up in support of this; no opposition was
raised.

>>> 30 Mar 2004 
<[email-masked]>

Eric Rosenfeld:
4) Still need to define the "blank" cname that Microsoft requested. It
is currently defined as [special "blank"
name], and this needs to be resolved before the draft can be posted.

Sam Hartman:
I still consider the issue of whether this is allowed open.
I'm waiting for Larry to reply to my comment about moving this to referals.

Larry Zhu:
We are fine with moving it to referrals.

RESOLVED - The text changes Brian described appeared in pkinit-19, and
the name canonicalization feature will be moved to referrals.

===========================================================================
===
*OPEN* 024 - cname mapping proposal

>>> 19 Apr 2004 
<[email-masked]
ev.microsoft.com>

Larry Zhu made a detailed proposal about how he wants client name mapping
to work.  There was ensuing discussion, at the end of which there appeared
to maybe concensus on how this should work.  It is unclear to me whether
and what text is to be added to the document.

>>> 27 Apr 2004 
<[email-masked]
ev.microsoft.com>

2) we should define mandatory-to-implement certificate mapping, this is
the way toward having interoperable and consistent behavior among
different implementations. I can send the initial proposal for this
item.

RESOLVED? - See #023

===========================================================================
===
*DONE* 025 - ASN.1 module appendix

>>> 30 Mar 2004 
<[email-masked]>

Eric Rosenfeld:
We think it would be a good idea to have a complete ASN.1 module in an 
Appendix.

>>> 17 May 2004 <[email-masked]>

Love posted an ASN.1 module for the appendix

Brian: Should ASN.1 be removed from the body?
Love: No; include it where it is discussed
Jeff Hutzelman: Agree; this worked well for clarifications.  Also it must
actually compile or the IESG will reject the document.
Love: It compiles.

RESOLVED - ASN.1 module appendix appears in pkinit-20

===========================================================================
===
*OPEN* 026 - Unconstrained Integers (Love #6)

>>> 20 Feb 2004 <[email-masked]>

Love:
- INTEGER usage ? should be uint32/int32 ?

NOT YET RESOLVED - two uses of unconstrained INTEGER remain in pkinit-20

===========================================================================
===
*DONE* 027 - ASN.1 errata

>>> 20 Feb 2004 <[email-masked]>

Love:
- AnotherName is specified in RFC3280, drop
- Name is missing in IMPORT
- ValidationParms, isn't used (its part of DomainParameters)
- DomainParameters, isn't used but named, so I guess its ok to import
(but still pointless)
- EncryptionKey, PrincipalName, Realm, KerberosTime, Checksum, TypedData
should be IMPORTed from krb5 kerberos-clarifications.
- TypedData is named to TYPED-DATA in clarifications-05 AFAICT
- krb5 oid is defined in clarifications-05, but there it is named id-krb5

RESOLVED - All of these appear to have been fixed as of pkinit-19.

===========================================================================
===
*OPEN* 028 - Nonce type?

>>> 20 Feb 2004 <[email-masked]>

Love:
- General question; should there be a kerberos nonce type in clarifications
  and should it be used by PKINIT

===========================================================================
===
*DONE* 029 - More ASN.1 errata

>>> 30 Mar 2004 
<[email-masked]>

        - The latest draft imported the wrong ASN.1 module for PKIX. It
imported PKIX1Explicit93, but RFC3280 (and RFC2459 before it) use
PKIX1Explicit88.

        - Incorrect Import statements, and multiple Imports for the same
module. A single module in an appendix would allow for a single import
for each module.

RESOLVED - Fixed in pkinit-20

===========================================================================
===
*XXXX* 030 - What key should the reply be enveloped with in the encKey 
case? (Love #1)

>>> 21 Apr 2004 <[email-masked]>

===========================================================================
===
*OPEN* 031 - Which encoding - DER vs BER? (Love #2)

>>> 21 Apr 2004 <[email-masked]>

Doc: Kerberos requires DER
Brian: Agree
Sam: Kerberos PDU's must use DER, but what about CMS?
Doc: FWIW PacketCable mandates DER for everything

Concensus seems to be that DER can and should be mandated.

>>> 2 Jun 2004 
<[email-masked]
ev.microsoft.com>
Larry:
I do not know a consensus can be reached if we enforce restrictions on
the encoding to the CMS objects.

I did not think interoperability (between what?) was possible here;
otherwise, this draft is not close to be finalized.

Love:
I think we should recomend DER, but it all depends on if its possible to
tweek the CMS lib the implementor is using.

[See also #035]

XXX love has recently pointed out a case where it may not
be possible to mandate DER.  This is still open...

===========================================================================
===
*DONE* 032 - What is encryptedContentType? (Love #3)

>>> 21 Apr 2004 <[email-masked]>

Doc: Looks like an error; should be contentType
Brian: Agree; fixed

RESOLVED - fixed in pkinit-20

===========================================================================
===
*DONE* 033 - What is encryptionCert? (Love #4)

>>> 21 Apr 2004 <[email-masked]>

Doc and Love seem to agree that they can't figure out what this is for,
but that it can't be useful for anything since it is not signed.  They
propose eliminating it if no one can comment on why it is there.  Sam
agrees provided that MS people don't object when they get back.

RESOLVED - removed in pkinit-20

===========================================================================
===
*OPEN* 034 - subjectAltName/OtherName issues (Love #7)

>>> 21 Apr 2004 <[email-masked]>

Love:
7) Talking about the subjectAltName and OtherName, that is the syntax and
   semantics when it it is uesd in Name Constraints ? And how does that
   apply to the use of OtherName in subjectAltName for pk-init ?

   <[email-masked]>

   pkix only define syntax for id-krb5, not sematics. how do I make
   restrictions on OtherName ? ie CA trusted for authentiation but not
   authorization.

NOT YET RESOLVED - no comments seen to this

===========================================================================
===
*OPEN* 035 - Wrap CMS objects in octet-strings?

>>> 1 Jun 2004 
<[email-masked]
ev.microsoft.com>

Larry Zhu:
I think it is a fine idea to specify the CMS objects as OCTET strings. I
do not know how, otherwise, one can use existing CMS libraries for the
PKINIT messages. This way we can also abstract better the CMS objects.

Love: Support
Sam: Agree in principle; not sure about delays or interop issues
Nico: Support
Larry: Doesn't think it is a delay
Nico: We were trying to avoid incompatible changes; maybe we have enough
problems now that this is no longer a goal.  Also, Love's proposal is not
really backward-incompatible since you can use the DER tag to determine
whether the wrapper is there or not.

Love: Lets wrap all cms types with "[N] IMPLICIT OCTET STRING".

NOT YET RESOLVED - we appear to have concensus on this issue, but the
text has not yet changed as of pkinit-20.  Need a volunteer to submit
new text pronto.
===========================================================================
===
*DONE* 036 - KDC Certificates?

>>> 21 Apr 2004 <[email-masked]>

Love:
How does the client verify its the kdc that signed the reply and not
someone else ?

Since noone publicly comments on this, I propose that something this this
is added:

"

If the client has external information as to the expected identity of the
KDC, the identity check MAY be omitted.

If a subjectAltName extension of type dNSName or iPAddress (if the KDC was
specifed by IP address instead of name) is part of the KDC's certificate
the client MUST check that it matches that KDC it tried to talk
to. Matching rules is specified by [RFC2459].

Client MUST check that the the KDC certificate have a extendedKeyUsage oid
id-kerberosPkinitKDC [TBD] set.

"

RESOLVED - text added in pkinit-20
===========================================================================
===
*NEW* 037 - ASN.1 module inconsistency

The contents of the ASN.1 module appendix are not consistent with the
ASN.1 fragments scattered throughout the text.  For example, the
definition of PA-PK-AS-REQ in the appendix lacks the kdcCert field,
which is present in the definition in section 3.2.1.

Also, the introductory text at the end of section 3.1.2 should
specify that in the event of misalignment between the appendix and
the fragments in the text, the appendix is normative.

===========================================================================
===
*NEW* 038 - DH groups selection
3.2.1, item (4) says DH parameters SHOULD be chosen from the first
or second Oakley groups (RFC2409).  IIRC this is insufficiently
strong and newer groups should be recommended

===========================================================================
===
*OPEN* 039 - Root CA cert in chain?

>>> 1 Jun 2004 <[email-masked]>

Martin Rex:
Since there was ambiguity about the "certificate chain" in SSL
(which has been documented in TLS), what does it mean here:

Should the certificate chain include the RootCA certificate?

Jeff Altman:
Usually including the RootCA certificate is optional.  It may be
included but should not
be required to be included in order to reduce the message size.  In
either case the RootCA
certificate should not be trusted (since it is self-signed) unless it
previously existed in a
locally maintained database of trusted RootCA Certificates.

Martin Rex then goes on to describe why it is a problem.

>>> 10 Jun 2004 <[email-masked]>

Sam Hartman:
Do we really have to specify certificate verification?  ISn't that a
CMS problem?  Or to the extent that we do have to profile aspects of
it is it clearly specified what we must profile?

>>> 11 Jun 2004 <[email-masked]>

Jeff Altman:
I believe the following text should be added to the document:

    "Certificate Path Validation MUST be performed according to the
    requirements and algorithm specified by the Internet X.509 Public
    Key Infrastructure Certificate and Certificate Revocation List (CRL)
    Profile [RFC 3280]"

<much discussion about whether this is a good idea>

NOT YET RESOLVED

===========================================================================
===
*OPEN* 040 - encryption certificate change not protected

>>> 22 Jul 2004 <[email-masked]>

Love:
* Encryption certificate is removed

"3.2.  PKINIT Preauthentication Syntax and Use"

Still contains references to this, the list of certificates are in the CMS
part of the message, and thus unsigned.

There is that issue that it might be unwise to use the same rsa-key to
encrypt data that was used to sign data.

    4.  The certificates field MUST contain at least a signature
        verification certificate chain that the KDC can use to
        verify the signature over the AuthPack.

        Additionally, the
        client MAY insert an encryption certificate chain, if
        (for example) the client is not using ephemeral-ephemeral
        Diffie-Hellman.

---

From: Love <[email-masked]>
Date: Tue, 03 Aug 2004 11:14:30 +0200

>   I think we need a volunteer to write this text.

If we use IMPLICIT OCTET STRING, just like larry poposed, the wire format
doesn't change. ContentInfo is not enough, its part of CMS. The question is
if we want too keep ContentInfo (wire compat) or not (more wrapping is good
?)

>       to implement PKINIT using off-the-shelf CMS libraries?

You have to use IMPLICIT OCTET STRING (or ANY) to make it work if you have
an asn1 parser that verify that the content is (or only handle) DER.

Love

---

From: Love <[email-masked]>
Date: Wed, 04 Aug 2004 23:23:36 +0200

>   I don't see this addressed in discussion on the mailing list.

with what cert should the kdc use when it reply, the key that the signed
request can in with ? in that case we might have a problem since many CA
don't allow encryption with certificates (KU bit missing).

Love

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Aug 2004 17:37:06 -0400

>>>>> "Love" == Love  <[email-masked]> writes:

    Love> Jeffrey Hutzelman <[email-masked]> writes:

    >> encKey case? (Love #1) I don't see this addressed in discussion
    >> on the mailing list.

    Love> with what cert should the kdc use when it reply, the key
    Love> that the signed request can in with ? 

This was my understanding.

    Love> in that case we might
    Love> have a problem since many CA don't allow encryption with
    Love> certificates (KU bit missing).

I hate PKI.

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Aug 2004 17:21:14 +0200 (MET DST)

>     Love> certificates (KU bit missing).

Certs may also not be usable for encryption for technical reasons,
not just CA policy reasons.  DSA certs do exist and there may
be other signature only algorithms.

Did we want to constrain PKINIT to RSA-certs? 

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Thu, 05 Aug 2004 12:19:11 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Did we want to constrain PKINIT to RSA-certs?

No, but there needs to be some mechanism to deal with this issue and
choosing the encryption cert.  My comment about PKI is not literally
true and I do understand why CAs have policy reasons and why there are
technical problems with some certs being used for encryption.