Subject: PKINIT-31, text arts

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 21 Dec 2005 09:52:11 -0800

The following email stuck in outbox yesterday, sending it out now.

------

Section 1 is replcated with the following and Nico's test arts are
included. Please review. Thanks.
-------------------

1.  Introduction

   The Kerberos V5 protocol [RFC4120] involves use of a trusted third
   party known as a Key Distribution Service (KDC) to negotiate shared
   session keys between clients and services and provide mutual
   authentication between them.

   The corner-stone of Kerberos V5 is the Ticket and the Authenticator.
   A Ticket encapsulates a symmetric key (the ticket session key) in an
   envelope (a public message) intended for a specific service.  The
   contents of the Ticket are encrypted with a symmetric key shared
   between the service principal and the issuing KDC.  The encrypted
   part of the Ticket contains the client principal name, amongst other
   items.  An Authenticator is a record that can be shown to have been
   recently generated using the ticket session key in the associated
   Ticket.  The ticket session key is known by the client who requested
   the ticket.  The contents of the Authenticator are encrypted with the
   associated ticket session key.  The encrypted part of an
   Authenticator contains a timestamp and the client principal name,
   amongst other items.

   As shown in Figure 1 below, the Kerberos V5 protocol consists of the
   following message exchanges between the client and the KDC, and the
   client and the application service:

    - The Authentication Service (AS) Exchange

      The client obtains an "initial" ticket from the Kerberos
      authentication server (AS), typically a Ticket Granting Ticket
      (TGT).  The AS-REQ message and the AS-REP message are the request
      and the reply message respectively between the client and the AS.

    - The Ticket Granting Service (TGS) Exchange

      The client subsequently uses the TGT to authenticate and request a
      service ticket for a particular service, from the Kerberos ticket-
      granting server (TGS).  The TGS-REQ message and the TGS-REP
      message are the request and the reply message respectively between
      the client and the TGS.

    - The Client/Server Authentication Protocol(AP) Exchange

      The client then makes a request with an AP-REQ message, consisting
      of a service ticket and an authenticator that certifies the
      client's possession of the ticket session key.  The server may
      optionally reply with an AP-REP message.  AP exchanges typically
      negotiate session specific symmetric keys.

   Usually, the AS and TGS are integrated in a single device as known as
   the KDC.

          Figure 1:  The Message Exchanges in the Kerberos V5 Protocol

                              +--------------+
                   +--------->|  KDC         |
           AS-REQ /   +-------|              |
                 /   /        +--------------+
                /   /          ^           |
               /    |AS-REP   /            |
              |     |        / TGS-REQ     + TGS-REP
              |     |       /             /
              |     |      /             /
              |     |     /   +---------+
              |     |    /   /
              |     |   /   /
              |     |  /   /
              |     v /   v
             ++-------+------+             +-----------------+
             |  Client       +------------>|  Application    |
             |               |    AP-REQ   |  Server         |
             |               |<------------|                 |
             +---------------+    AP-REP   +-----------------+

   In the AS exchange, the KDC reply contains the ticket session key,
   amongst other items, that is encrypted using a key (the AS reply key)
   shared between the client and the KDC.  The AS reply key is typically
   derived from the client's password for human users.  Therefore for
   human users the attack resistance strength of the Kerberos protocol
   is no stronger than the strength of their passwords.

   The use of asymmetric cryptography in the form of X.509 certificates
   [RFC3280] is popular for facilitating non-repudiation and perfect
   secrecy.  An established Public Key Infrastructure (PKI) provides key
   management and key distribution mechanisms that can be used to
   establish authentication and secure communication.  Adding public-key
   cryptography to Kerberos provides a nice congruence to public-key
   protocols, obviates the human users' burden to manage strong
   passwords, and allows Kerberized applications to take advantage of
   existing key services and identity management.

   The advantage afforded by the Kerberos TGT is that the client exposes
   his long-term secrets only once.  The TGT and its associated session
   key can then be used for any subsequent service ticket requests.  One
   result of this is that all further authentication is independent of
   the method by which the initial authentication was performed.
   Consequently, initial authentication provides a convenient place to
   integrate public-key cryptography into Kerberos authentication.  In
   addition, the use of symmetric cryptography after the intial exchange
   is prefered for performance.

   This document describes the methods and data formats using which the
   client and the KDC can use public and private key pairs to mutually
   authenticate in the AS exchange and negotiate the AS reply key, known
   only by the client and the KDC, to encrypt the AS-REP sent by the
   KDC.

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 21 Dec 2005 12:54:55 -0500

I approve!!!!

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Dec 2005 11:59:30 -0600

> > included. Please review. Thanks.

Do double check that the ASCII art is reasonably accurate please.  I
think I got it right, but do check it.

Also, I don't think I included a legend, but it should be obvious that I
used square brackets to indicate optionality and asterisks to indicate
that a field is a SEQUENCE OF.

Nico
--

---

From: Chaskiel M Grundman <[email-masked]>
Date: Wed, 21 Dec 2005 15:08:04 -0500

> included. Please review. Thanks.

Wow. I like this text a lot.  (I'm not sure I think that 
kerberos-in-a-nutshell needs to be in this document, but others do. The 
'justification' for pkinit is needed, and is much clearer now)

I'm not sure the mention of PFS is a good idea. while there is PFS of the 
reply key when DH is used, the rest of kerberos does not provide PFS for 
TGS or service key compromises. We shouldn't suggest otherwise, even 
indirectly.

---

From: Martin Rex <[email-masked]>
Date: Thu, 29 Dec 2005 22:48:33 +0100 (MET)

> TGS or service key compromises. We shouldn't suggest otherwise, even

Larry's text says "perfect secrecy" not "perfect forward secrecy (PFS)",
although he probably meant to say that (then it should be corrected).

And please purge the term "non-repudiation" completely from the document.

I extremely dislike it when a PKI-related spec uses the term
"non-repudiation", because in the majority of uses today (>99%),
non-repudiation is not only *NOT* provided -- but instead most uses
completely void PKI credentials (=keypairs) for use in environments
which could provide non-repudiation.

The SPKM spec (rfc2025) is an example of a spec that shows just how
little its author understood what non-repudiation really means.

SPKM requires the longterm credentials not only to sign binary
blobs on each and every security context establishment, it also
suggests to use them for "message integrity protection".
Depending on the application scenario, this will result in
thousands of automatically signed binary blobs of data...

-Martin