Subject: RE: PKINIT issues, proposals

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 12 Jul 2004 21:13:17 -0700

For proposal #1, the trade-offs of including/excluding OSCP tunneling
are mostly understood, and if it is the working group's decision to
withdraw the tunneling from the draft, we will move on and pursue this
separately. 

For proposal #3, we need to add a server side nonce to enable
static-static DH, I am waiting to see a proposal from Sam for that
(mostly how to use the PRF in the kcrypto to accomplish this). But this
should not block the next version of this draft.

Please by all means publish a new draft ASAP, so that we can verify the
rest of concerns/comments have been properly addressed.

We Microsoft will absolutely need the PKINIT draft advanced to the last
call status no later than Oct 2004, or it will not make into our next
release, and we are strongly motivated to move the draft forward.

JK and I will stay at San Diego most of the week in the upcoming IETF
60, we would hope to get interested parties to sit together and iron out
any remaining wrinkles.

Thanks,

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Brian Tung
Sent: Monday, July 12, 2004 3:40 PM
To: [email-masked]
Subject: PKINIT issues, proposals

There has been much discussion on various PKINIT issues over the last
few weeks, but it seems (at least to us) that no clear consensus has
been reached.  In an attempt to foster enough consensus to proceed, we
make the following proposals.  We emphasize that these proposals are not
intended to suppress any particular viewpoint, or predicated on absolute
certainties--only that our principal goal is to move the draft ahead
based on available information.

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.

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.

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
    agreement.  The crypto draft determines how many bits of the shared
    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.

Brian Tung <[email-masked]>
Sasha Medvinsky <[email-masked]> Eric Rosenfeld
<[email-masked]>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 13 Jul 2004 11:12:48 -0400

> 60, we would hope to get interested parties to sit together and iron out

This reminds me to bring up an important point, which some participants in 
this group seem to keep forgetting.

IETF meetings are a week-long event.  There are a lot of WG meetings and 
BOF's.  Scheduling is affected by the time needed for each meeting, the 
conflicts that WG chairs have asked to avoid, and the avilability of 
meeting space.  They are also heavily affected by the schedules of the 
AD's, who typically have someplace to be during every meeting slot, and 
sometimes more than one place to be.

That means that as needs change, the schedule can change significantly 
fairly late.  The DRAFT agenda which currently appears on the IETF is 
_very_ preliminary and already quite out of date.  Anyone who plans to be 
there only on Wednesday afternoon on the basis of that agenda is risking 
the meeting being moved out from under them.  If that happens THERE IS 
NOTHING DOUG OR I CAN DO ABOUT IT, and we will not even ask.  We played 
this game in Minneapolis, and it sucked.  I feel like we squandered a lot 
of goodwill with Russ and Marcia during that meeting, and I'm not anxious 
to do so again.

-- Jeff