Rename context handle lifetime to endtime

[heimdal.git] / doc / standardisation / draft-ietf-cat-kerberos-pk-init-10.txt

INTERNET-DRAFT                                                Brian Tung
draft-ietf-cat-kerberos-pk-init-10.txt                   Clifford Neuman
Updates: RFC 1510                                                    ISI
expires April 30, 2000                                       Matthew Hur
                                                   CyberSafe Corporation
                                                           Ari Medvinsky
                                                                  Excite
                                                         Sasha Medvinsky
                                                      General Instrument
                                                               John Wray
                                                   Iris Associates, Inc.
                                                        Jonathan Trostle
                                                                   Cisco

    Public Key Cryptography for Initial Authentication in Kerberos

0.  Status Of This Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC 2026.  Internet-Drafts are
    working documents of the Internet Engineering Task Force (IETF),
    its areas, and its working groups.  Note that other groups may also
    distribute working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time.  It is inappropriate to use Internet-Drafts
    as reference material or to cite them other than as "work in
    progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

    To learn the current status of any Internet-Draft, please check
    the "1id-abstracts.txt" listing contained in the Internet-Drafts
    Shadow Directories on ftp.ietf.org (US East Coast),
    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
    munnari.oz.au (Pacific Rim).

    The distribution of this memo is unlimited.  It is filed as
    draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30,
    2000.  Please send comments to the authors.

1.  Abstract

    This document defines extensions (PKINIT) to the Kerberos protocol
    specification (RFC 1510 [1]) to provide a method for using public
    key cryptography during initial authentication.  The methods
    defined specify the ways in which preauthentication data fields and
    error data fields in Kerberos messages are to be used to transport
    public key data.

2.  Introduction

    The popularity of public key cryptography has produced a desire for
    its support in Kerberos [2].  The advantages provided by public key
    cryptography include simplified key management (from the Kerberos
    perspective) and the ability to leverage existing and developing
    public key certification infrastructures.

    Public key cryptography can be integrated into Kerberos in a number
    of ways.  One is to associate a key pair with each realm, which can
    then be used to facilitate cross-realm authentication; this is the
    topic of another draft proposal.  Another way is to allow users with
    public key certificates to use them in initial authentication.  This
    is the concern of the current document.

    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
    combination with digital signature keys as the primary, required
    mechanism.  It also allows for the use of RSA keys and/or (static)
    Diffie-Hellman certificates.  Note in particular that PKINIT supports
    the use of separate signature and encryption keys.

    PKINIT enables access to Kerberos-secured services based on initial
    authentication utilizing public key cryptography.  PKINIT utilizes
    standard public key signature and encryption data formats within the
    standard Kerberos messages.  The basic mechanism is as follows:  The
    user sends an AS-REQ message to the KDC as before, except that if that
    user is to use public key cryptography in the initial authentication
    step, his certificate and a signature accompany the initial request
    in the preauthentication fields.  Upon receipt of this request, the
    KDC verifies the certificate and issues a ticket granting ticket
    (TGT) as before, except that the encPart from the AS-REP message
    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
    derived key or the user's public key.  This message is authenticated
    utilizing the public key signature of the KDC.

    Note that PKINIT does not require the use of certificates.  A KDC
    may store the public key of a principal as part of that principal's
    record.  In this scenario, the KDC is the trusted party that vouches
    for the principal (as in a standard, non-cross realm, Kerberos
    environment).  Thus, for any principal, the KDC may maintain a
    secret key, a public key, or both.

    The PKINIT specification may also be used as a building block for
    other specifications.  PKCROSS [3] utilizes PKINIT for establishing
    the inter-realm key and associated inter-realm policy to be applied
    in issuing cross realm service tickets.  As specified in [4],
    anonymous Kerberos tickets can be issued by applying a NULL
    signature in combination with Diffie-Hellman in the PKINIT exchange.
    Additionally, the PKINIT specification may be used for direct peer
    to peer authentication without contacting a central KDC. This
    application of PKINIT is described in PKTAPP [5] and is based on
    concepts introduced in [6, 7]. For direct client-to-server
    authentication, the client uses PKINIT to authenticate to the end
    server (instead of a central KDC), which then issues a ticket for
    itself.  This approach has an advantage over TLS [8] in that the
    server does not need to save state (cache session keys).
    Furthermore, an additional benefit is that Kerberos tickets can
    facilitate delegation (see [9]).

3.  Proposed Extensions

    This section describes extensions to RFC 1510 for supporting the
    use of public key cryptography in the initial request for a ticket
    granting ticket (TGT).

    In summary, the following change to RFC 1510 is proposed:

        * Users may authenticate using either a public key pair or a
          conventional (symmetric) key.  If public key cryptography is
          used, public key data is transported in preauthentication
          data fields to help establish identity.  The user presents
          a public key certificate and obtains an ordinary TGT that may
          be used for subsequent authentication, with such
          authentication using only conventional cryptography.

    Section 3.1 provides definitions to help specify message formats.
    Section 3.2 describes the extensions for the initial authentication
    method.

3.1.  Definitions

    The extensions involve new preauthentication fields; we introduce
    the following preauthentication types:

        PA-PK-AS-REQ                            14
        PA-PK-AS-REP                            15

    The extensions also involve new error types; we introduce the
    following types:

        KDC_ERR_CLIENT_NOT_TRUSTED              62
        KDC_ERR_KDC_NOT_TRUSTED                 63
        KDC_ERR_INVALID_SIG                     64
        KDC_ERR_KEY_TOO_WEAK                    65
        KDC_ERR_CERTIFICATE_MISMATCH            66
        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
        KDC_ERR_INVALID_CERTIFICATE             71
        KDC_ERR_REVOKED_CERTIFICATE             72
        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
        KDC_ERR_CLIENT_NAME_MISMATCH            75
        KDC_ERR_KDC_NAME_MISMATCH               76

    We utilize the following typed data for errors:

        TD-PKINIT-CMS-CERTIFICATES             101
        TD-KRB-PRINCIPAL                       102
        TD-KRB-REALM                           103
        TD-TRUSTED-CERTIFIERS                  104
        TD-CERTIFICATE-INDEX                   105

    We utilize the following encryption types (which map directly to
    OIDs):

        dsaWithSHA1-CmsOID                       9
        md5WithRSAEncryption-CmsOID             10
        sha1WithRSAEncryption-CmsOID            11
        rc2CBC-EnvOID                           12
        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
        des-ede3-cbc-Env-OID                    15

    These mappings are provided so that a client may send the
    appropriate enctypes in the AS-REQ message in order to indicate
    support for the corresponding OIDs (for performing PKINIT).

    In many cases, PKINIT requires the encoding of the X.500 name of a
    certificate authority as a Realm.  When such a name appears as
    a ream it will be represented using the "other" form of the realm
    name as specified in the naming constraints section of RFC1510.
    For a realm derived from an X.500 name, NAMETYPE will have the value
    X500-RFC2253.  The full realm name will appear as follows:

        <nametype> + ":" + <string>

    where nametype is "X500-RFC2253" and string is the result of doing
    an RFC2253 encoding of the distinguished name, i.e.

        "X500-RFC2253:" + RFC2253Encode(DistinguishedName)

    where DistinguishedName is an X.500 name, and RFC2253Encode is a
    function returing a readable UTF encoding of an X.500 name, as
    defined by RFC 2253 [14] (part of LDAPv3 [18]).

    To ensure that this encoding is unique, we add the following rule
    to those specified by RFC 2253:

        The order in which the attributes appear in the RFC 2253
        encoding must be the reverse of the order in the ASN.1
        encoding of the X.500 name that appears in the public key
        certificate. The order of the relative distinguished names
        (RDNs), as well as the order of the AttributeTypeAndValues
        within each RDN, will be reversed. (This is despite the fact
        that an RDN is defined as a SET of AttributeTypeAndValues, where
        an order is normally not important.)

    Similarly, in cases where the KDC does not provide a specific
    policy based mapping from the X.500 name or X.509 Version 3
    SubjectAltName extension in the user's certificate to a Kerberos
    principal name, PKINIT requires the direct encoding of the X.500
    name as a PrincipalName.  In this case, the name-type of the
    principal name shall be set to KRB_NT-X500-PRINCIPAL.  This new
    name type is defined in RFC 1510 as:

        KRB_NT_X500_PRINCIPAL    6

    The name-string shall be set as follows:

        RFC2253Encode(DistinguishedName)

    as described above.  When this name type is used, the principal's
    realm shall be set to the certificate authority's distinguished
    name using the X500-RFC2253 realm name format described earlier in
    this section

    RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:

        PrincipalName ::=   SEQUENCE {
                        name-type[0]     INTEGER,
                        name-string[1]   SEQUENCE OF GeneralString
        }

    For the purposes of encoding an X.500 name within this structure,
    the name-string shall be encoded as a single GeneralString.

    Note that name mapping may be required or optional based on
    policy.  All names must conform to validity requirements as given
    in RFC 1510.

3.1.1.  Encryption and Key Formats

    In the exposition below, we use the terms public key and private
    key generically.  It should be understood that the term "public
    key" may be used to refer to either a public encryption key or a
    signature verification key, and that the term "private key" may be
    used to refer to either a private decryption key or a signature
    generation key.  The fact that these are logically distinct does
    not preclude the assignment of bitwise identical keys for RSA
    keys.

    In the case of Diffie-Hellman, the key shall be produced from the
    agreed bit string as follows:

        * Truncate the bit string to the appropriate length.
        * Rectify parity in each byte (if necessary) to obtain the key.

    For instance, in the case of a DES key, we take the first eight
    bytes of the bit stream, and then adjust the least significant bit
    of each byte to ensure that each byte has odd parity.

3.1.2. Algorithm Identifiers

    PKINIT does not define, but does permit, the algorithm identifiers
    listed below.

3.1.2.1. Signature Algorithm Identifiers

    The following signature algorithm identifiers specified in [11] and
    in [15] shall be used with PKINIT:

    id-dsa-with-sha1       (DSA with SHA1)
    md5WithRSAEncryption   (RSA with MD5)
    sha-1WithRSAEncryption (RSA with SHA1)

3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier

    The following algorithm identifier shall be used within the
    SubjectPublicKeyInfo data structure: dhpublicnumber

    This identifier and the associated algorithm parameters are
    specified in RFC 2459 [15].

3.1.2.3. Algorithm Identifiers for RSA Encryption

    These algorithm identifiers are used inside the EnvelopedData data
    structure, for encrypting the temporary key with a public key:

        rsaEncryption (RSA encryption, PKCS#1 v1.5)
        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)

    Both of the above RSA encryption schemes are specified in [16].
    Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
    CMS specification says that it will likely include PKCS#1 v2.0 in
    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
    vulnerability discovered in PKCS#1 v1.5.)

3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys

    These algorithm identifiers are used inside the EnvelopedData data
    structure in the PKINIT Reply, for encrypting the reply key with the
    temporary key:
        des-ede3-cbc (3-key 3-DES, CBC mode)
        rc2-cbc      (RC2, CBC mode)

    The full definition of the above algorithm identifiers and their
    corresponding parameters (an IV for block chaining) is provided in
    the CMS specification [11].

3.2.  Public Key Authentication

    Implementation of the changes in this section is REQUIRED for
    compliance with PKINIT.

3.2.1.  Client Request

    Public keys may be signed by some certification authority (CA), or
    they may be maintained by the KDC in which case the KDC is the
    trusted authority.  Note that the latter mode does not require the
    use of certificates.

    The initial authentication request is sent as per RFC 1510, except
    that a preauthentication field containing data signed by the user's
    private key accompanies the request:

    PA-PK-AS-REQ ::= SEQUENCE {
                                -- PA TYPE 14
        signedAuthPack          [0] SignedData
                                    -- defined in CMS [11]
                                    -- AuthPack (below) defines the data
                                    -- that is signed
        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
                                    -- CAs that the client trusts
        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
                                    -- as defined in CMS [11]
                                    -- specifies a particular KDC
                                    -- certificate if the client
                                    -- already has it;
        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
                                    -- For example, this may be the
                                    -- client's Diffie-Hellman
                                    -- certificate, or it may be the
                                    -- client's RSA encryption
                                    -- certificate.
    }

    TrustedCas ::= CHOICE {
        principalName         [0] KerberosName,
                                  -- as defined below
        caName                [1] Name
                                  -- fully qualified X.500 name
                                  -- as defined by X.509
        issuerAndSerial       [2] IssuerAndSerialNumber
                                  -- Since a CA may have a number of
                                  -- certificates, only one of which
                                  -- a client trusts
    }

    Usage of SignedData:
    The SignedData data type is specified in the Cryptographic
    Message Syntax, a product of the S/MIME working group of the IETF.
    - The encapContentInfo field must contain the PKAuthenticator
      and, optionally, the client's Diffie Hellman public value.
      - The eContentType field shall contain the OID value for
        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
        pkcs(1) pkcs7(7) data(1)
      - The eContent field is data of the type AuthPack (below).
    - The signerInfos field contains the signature of AuthPack.
    - The Certificates field, when non-empty, contains the client's
      certificate chain.  If present, the KDC uses the public key from
      the client's certificate to verify the signature in the request.
      Note that the client may pass different certificates that are used
      for signing or for encrypting.  Thus, the KDC may utilize a
      different client certificate for signature verification than the
      one it uses to encrypt the reply to the client.  For example, the
      client may place a Diffie-Hellman certificate in this field in
      order to convey its static Diffie Hellman certificate to the KDC to
      enable static-ephemeral Diffie-Hellman mode for the reply; in this
      case, the client does NOT place its public value in the AuthPack
      (defined below).  As another example, the client may place an RSA
      encryption certificate in this field.  However, there must always
      be (at least) a signature certificate.

    AuthPack ::= SEQUENCE {
        pkAuthenticator         [0] PKAuthenticator,
        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
                                    -- if client is using Diffie-Hellman
                                    -- (ephemeral-ephemeral only)
    }

    PKAuthenticator ::= SEQUENCE {
        kdcName                 [0] PrincipalName,
        kdcRealm                [1] Realm,
        cusec                   [2] INTEGER,
                                    -- for replay prevention as in RFC1510
        ctime                   [3] KerberosTime,
                                    -- for replay prevention as in RFC1510
        nonce                   [4] INTEGER
    }

    SubjectPublicKeyInfo ::= SEQUENCE {
        algorithm                   AlgorithmIdentifier,
                                    -- dhKeyAgreement
        subjectPublicKey            BIT STRING
                                    -- for DH, equals
                                    -- public exponent (INTEGER encoded
                                    -- as payload of BIT STRING)
    }   -- as specified by the X.509 recommendation [10]

    AlgorithmIdentifier ::= SEQUENCE {
        algorithm                   ALGORITHM.&id,
        parameters                  ALGORITHM.&type
    }   -- as specified by the X.509 recommendation [10]

    If the client passes an issuer and serial number in the request,
    the KDC is requested to use the referred-to certificate.  If none
    exists, then the KDC returns an error of type
    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
    other hand, the client does not pass any trustedCertifiers,
    believing that it has the KDC's certificate, but the KDC has more
    than one certificate.  The KDC should include information in the
    KRB-ERROR message that indicates the KDC certificate(s) that a
    client may utilize.  This data is specified in the e-data, which
    is defined in RFC 1510 revisions as a SEQUENCE of TypedData:

    TypedData ::=  SEQUENCE {
                    data-type      [0] INTEGER,
                    data-value     [1] OCTET STRING,
    } -- per Kerberos RFC 1510 revisions

    where:
    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
    data-value = CertificateSet // as specified by CMS [11]

    The PKAuthenticator carries information to foil replay attacks, and
    to bind the request and response.  The PKAuthenticator is signed
    with the client's signature key.

3.2.2.  KDC Response

    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
    type, the KDC attempts to verify the user's certificate chain
    (userCert), if one is provided in the request.  This is done by
    verifying the certification path against the KDC's policy of
    legitimate certifiers.  This may be based on a certification
    hierarchy, or it may be simply a list of recognized certifiers in a
    system like PGP.

    If the client's certificate chain contains no certificate signed by
    a CA trusted by the KDC, then the KDC sends back an error message
    of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data
    is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
    whose data-value is an OCTET STRING which is the DER encoding of

        TrustedCertifiers ::= SEQUENCE OF PrincipalName
                              -- X.500 name encoded as a principal name
                              -- see Section 3.1

    If while verifying a certificate chain the KDC determines that the
    signature on one of the certificates in the CertificateSet from
    the signedAuthPack fails verification, then the KDC returns an
    error of type KDC_ERR_INVALID_CERTIFICATE.  The accompanying
    e-data is a SEQUENCE of one TypedData (with type
    TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
    which is the DER encoding of the index into the CertificateSet
    ordered as sent by the client.

        CertificateIndex  ::= INTEGER
                              -- 0 = 1st certificate,
                              --     (in order of encoding)
                              -- 1 = 2nd certificate, etc

    The KDC may also check whether any of the certificates in the
    client's chain has been revoked.  If one of the certificates has
    been revoked, then the KDC returns an error of type
    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
    the certificate's revocation status is unknown or not
    available, then if required by policy, the KDC returns the
    appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
    cases, the affected certificate is identified by the accompanying
    e-data, which contains a CertificateIndex as described for
    KDC_ERR_INVALID_CERTIFICATE.

    If the certificate chain can be verified, but the name of the
    client in the certificate does not match the client's name in the
    request, then the KDC returns an error of type
    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
    field in this case.

    Finally, if the certificate chain is verified, but the KDC's name
    or realm as given in the PKAuthenticator does not match the KDC's
    actual principal name, then the KDC returns an error of type
    KDC_ERR_KDC_NAME_MISMATCH.  The accompanying e-data field is again
    a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
    TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
    STRING whose data-value is the DER encoding of a PrincipalName or
    Realm as defined in RFC 1510 revisions.

    Even if all succeeds, the KDC may--for policy reasons--decide not
    to trust the client.  In this case, the KDC returns an error message
    of type KDC_ERR_CLIENT_NOT_TRUSTED.

    If a trust relationship exists, the KDC then verifies the client's
    signature on AuthPack.  If that fails, the KDC returns an error
    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
    timestamp (ctime and cusec) in the PKAuthenticator to assure that
    the request is not a replay.  The KDC also verifies that its name
    is specified in the PKAuthenticator.

    If the clientPublicValue field is filled in, indicating that the
    client wishes to use Diffie-Hellman key agreement, then the KDC
    checks to see that the parameters satisfy its policy.  If they do
    not (e.g., the prime size is insufficient for the expected
    encryption type), then the KDC sends back an error message of type
    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
    private values for the response.

    The KDC also checks that the timestamp in the PKAuthenticator is
    within the allowable window and that the principal name and realm
    are correct.  If the local (server) time and the client time in the
    authenticator differ by more than the allowable clock skew, then the
    KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510.

    Assuming no errors, the KDC replies as per RFC 1510, except as
    follows.  The user's name in the ticket is determined by the
    following decision algorithm:

        1.  If the KDC has a mapping from the name in the certificate
            to a Kerberos name, then use that name.
            Else
        2.  If the certificate contains the SubjectAltName extention
            and the local KDC policy defines a mapping from the
            SubjectAltName to a Kerberos name, then use that name.
            Else
        3.  Use the name as represented in the certificate, mapping
            mapping as necessary (e.g., as per RFC 2253 for X.500
            names).  In this case the realm in the ticket shall be the
            name of the certifier that issued the user's certificate.

    Note that a principal name may be carried in the subject alt name
    field of a certificate. This name may be mapped to a principal
    record in a security database based on local policy, for example
    the subject alt name may be kerberos/principal@realm format.  In
    this case the realm name is not that of the CA but that of the
    local realm doing the mapping (or some realm name chosen by that
    realm).

    If a non-KDC X.509 certificate contains the principal name within
    the subjectAltName version 3 extension , that name may utilize
    KerberosName as defined below, or, in the case of an S/MIME
    certificate [17], may utilize the email address.  If the KDC
    is presented with as S/MIME certificate, then the email address
    within subjectAltName will be interpreted as a principal and realm
    separated by the "@" sign, or as a name that needs to be
    canonicalized.  If the resulting name does not correspond to a
    registered principal name, then the principal name is formed as
    defined in section 3.1.

    The trustedCertifiers field contains a list of certification
    authorities trusted by the client, in the case that the client does
    not possess the KDC's public key certificate.  If the KDC has no
    certificate signed by any of the trustedCertifiers, then it returns
    an error of type KDC_ERR_KDC_NOT_TRUSTED.

    KDCs should try to (in order of preference):
    1. Use the KDC certificate identified by the serialNumber included
       in the client's request.
    2. Use a certificate issued to the KDC by the client's CA (if in the
       middle of a CA key roll-over, use the KDC cert issued under same
       CA key as user cert used to verify request).
    3. Use a certificate issued to the KDC by one of the client's
       trustedCertifier(s);
    If the KDC is unable to comply with any of these options, then the
    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
    client.

    The KDC encrypts the reply not with the user's long-term key, but
    with the Diffie Hellman derived key or a random key generated
    for this particular response which is carried in the padata field of
    the TGS-REP message.

    PA-PK-AS-REP ::= CHOICE {
                            -- PA TYPE 15
        dhSignedData       [0] SignedData,
                            -- Defined in CMS and used only with
                            -- Diffie-Hellman key exchange (if the
                            -- client public value was present in the
                            -- request).
                            -- This choice MUST be supported
                            -- by compliant implementations.
        encKeyPack         [1] EnvelopedData,
                            -- Defined in CMS
                            -- The temporary key is encrypted
                            -- using the client public key
                            -- key
                            -- SignedReplyKeyPack, encrypted
                            -- with the temporary key, is also
                            -- included.
    }

    Usage of SignedData:
    If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP
    provides authenticated Diffie-Hellman parameters of the KDC.  The
    reply key used to encrypt part of the KDC reply message is derived
    from the Diffie-Hellman exchange:
    - Both the KDC and the client calculate a secret value (g^ab mod p),
      where a is the client's private exponent and b is the KDC's
      private exponent.
    - Both the KDC and the client take the first N bits of this secret
      value and convert it into a reply key.  N depends on the reply key
      type.
    - If the reply key is DES, N=64 bits, where some of the bits are
      replaced with parity bits, according to FIPS PUB 74.
    - If the reply key is (3-key) 3-DES, N=192 bits, where some of the
      bits are replaced with parity bits, according to FIPS PUB 74.
    - The encapContentInfo field must contain the KdcDHKeyInfo as
      defined below.
      - The eContentType field shall contain the OID value for
        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
        pkcs(1) pkcs7(7) data(1)
    - The certificates field must contain the certificates necessary
      for the client to establish trust in the KDC's certificate
      based on the list of trusted certifiers sent by the client in
      the PA-PK-AS-REQ.  This field may be empty if the client did
      not send to the KDC a list of trusted certifiers (the
      trustedCertifiers field was empty, meaning that the client
      already possesses the KDC's certificate).
    - The signerInfos field is a SET that must contain at least one
      member, since it contains the actual signature.

    KdcDHKeyInfo ::= SEQUENCE {
                              -- used only when utilizing Diffie-Hellman
      nonce                 [0] INTEGER,
                                -- binds responce to the request
      subjectPublicKey      [2] BIT STRING
                                -- Equals public exponent (g^a mod p)
                                -- INTEGER encoded as payload of
                                -- BIT STRING
    }

    Usage of EnvelopedData:
    The EnvelopedData data type is specified in the Cryptographic
    Message Syntax, a product of the S/MIME working group of the IETF.
    It contains an temporary key encrypted with the PKINIT
    client's public key.  It also contains a signed and encrypted
    reply key.
    - The originatorInfo field is not required, since that information
      may be presented in the signedData structure that is encrypted
      within the encryptedContentInfo field.
    - The optional unprotectedAttrs field is not required for PKINIT.
    - The recipientInfos field is a SET which must contain exactly one
      member of the KeyTransRecipientInfo type for encryption
      with an RSA public key.
         - The encryptedKey field (in KeyTransRecipientInfo) contains
           the temporary key which is encrypted with the PKINIT client's
           public key.
    - The encryptedContentInfo field contains the signed and encrypted
      reply key.
      - The contentType field shall contain the OID value for
        id-signedData: iso(1) member-body(2) us(840) rsadsi(113549)
        pkcs(1) pkcs7(7) signedData(2)
      - The encryptedContent field is encrypted data of the CMS type
        signedData as specified below.
        - The encapContentInfo field must contains the ReplyKeyPack.
          - The eContentType field shall contain the OID value for
            id-data: iso(1) member-body(2) us(840) rsadsi(113549)
            pkcs(1) pkcs7(7) data(1)
          - The eContent field is data of the type ReplyKeyPack (below).
        - The certificates field must contain the certificates necessary
          for the client to establish trust in the KDC's certificate
          based on the list of trusted certifiers sent by the client in
          the PA-PK-AS-REQ.  This field may be empty if the client did
          not send to the KDC a list of trusted certifiers (the
          trustedCertifiers field was empty, meaning that the client
          already possesses the KDC's certificate).
        - The signerInfos field is a SET that must contain at least one
          member, since it contains the actual signature.

    ReplyKeyPack ::= SEQUENCE {
                              -- not used for Diffie-Hellman
        replyKey             [0] EncryptionKey,
                                 -- used to encrypt main reply
                                 -- ENCTYPE is at least as strong as
                                 -- ENCTYPE of session key
        nonce                [1] INTEGER,
                                 -- binds response to the request
                                 -- must be same as the nonce
                                 -- passed in the PKAuthenticator
    }

    Since each certifier in the certification path of a user's
    certificate is equivalent to a separate Kerberos realm, the name
    of each certifier in the certificate chain must be added to the
    transited field of the ticket.  The format of these realm names is
    defined in Section 3.1 of this document.  If applicable, the
    transit-policy-checked flag should be set in the issued ticket.

    The KDC's certificate(s) must bind the public key(s) of the KDC to
    a name derivable from the name of the realm for that KDC.  X.509
    certificates shall contain the principal name of the KDC
    (defined in section 8.2 of RFC 1510) as the SubjectAltName version
    3 extension. Below is the definition of this version 3 extension,
    as specified by the X.509 standard:

        subjectAltName EXTENSION ::= {
            SYNTAX GeneralNames
            IDENTIFIED BY id-ce-subjectAltName
        }

        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName

        GeneralName ::= CHOICE {
            otherName       [0] INSTANCE OF OTHER-NAME,
            ...
        }

        OTHER-NAME ::= TYPE-IDENTIFIER

    In this definition, otherName is a name of any form defined as an
    instance of the OTHER-NAME information object class. For the purpose
    of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
    be chosen and replaced by the type KerberosName:

        KerberosName ::= SEQUENCE {
          realm           [0] Realm,
                              -- as defined in RFC 1510
          principalName   [1] PrincipalName,
                              -- as defined in RFC 1510
        }

    This specific syntax is identified within subjectAltName by setting
    the OID id-ce-subjectAltName to krb5PrincipalName, where (from the
    Kerberos specification) we have

        krb5 OBJECT IDENTIFIER ::= { iso (1)
                                     org (3)
                                     dod (6)
                                     internet (1)
                                     security (5)
                                     kerberosv5 (2) }

        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }

    (This specification may also be used to specify a Kerberos name
    within the user's certificate.)  The KDC's certificate may be signed
    directly by a CA, or there may be intermediaries if the server resides
    within a large organization, or it may be unsigned if the client
    indicates possession (and trust) of the KDC's certificate.

    The client then extracts the random key used to encrypt the main
    reply.  This random key (in encPaReply) is encrypted with either the
    client's public key or with a key derived from the DH values
    exchanged between the client and the KDC.  The client uses this
    random key to decrypt the main reply, and subsequently proceeds as
    described in RFC 1510.

3.2.3. Required Algorithms

    Not all of the algorithms in the PKINIT protocol specification have
    to be implemented in order to comply with the proposed standard.
    Below is a list of the required algorithms:

    - Diffie-Hellman public/private key pairs
      - utilizing Diffie-Hellman ephemeral-ephemeral mode
    - SHA1 digest and DSA for signatures
    - 3-key triple DES keys derived from the Diffie-Hellman Exchange
    - 3-key triple DES Temporary and Reply keys

4.  Logistics and Policy

    This section describes a way to define the policy on the use of
    PKINIT for each principal and request.

    The KDC is not required to contain a database record for users
    who use public key authentication.  However, if these users are
    registered with the KDC, it is recommended that the database record
    for these users be modified to an additional flag in the attributes
    field to indicate that the user should authenticate using PKINIT.
    If this flag is set and a request message does not contain the
    PKINIT preauthentication field, then the KDC sends back as error of
    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
    field of type PA-PK-AS-REQ must be included in the request.

5.  Security Considerations

    PKINIT raises a few security considerations, which we will address
    in this section.

    First of all, PKINIT introduces a new trust model, where KDCs do not
    (necessarily) certify the identity of those for whom they issue
    tickets.  PKINIT does allow KDCs to act as their own CAs, in order
    to simplify key management, but one of the additional benefits is to
    align Kerberos authentication with a global public key
    infrastructure.  Anyone using PKINIT in this way must be aware of
    how the certification infrastructure they are linking to works.

    Secondly, PKINIT also introduces the possibility of interactions
    between different cryptosystems, which may be of widely varying
    strengths.  Many systems, for instance, allow the use of 512-bit
    public keys.  Using such keys to wrap data encrypted under strong
    conventional cryptosystems, such as triple-DES, is inappropriate;
    it adds a weak link to a strong one at extra cost.  Implementors
    and administrators should take care to avoid such wasteful and
    deceptive interactions.

    Lastly, PKINIT calls for randomly generated keys for conventional
    cryptosystems.  Many such systems contain systematically "weak"
    keys.  PKINIT implementations MUST avoid use of these keys, either
    by discarding those keys when they are generated, or by fixing them
    in some way (e.g., by XORing them with a given mask).  These
    precautions vary from system to system; it is not our intention to
    give an explicit recipe for them here.

6.  Transport Issues

    Certificate chains can potentially grow quite large and span several
    UDP packets; this in turn increases the probability that a Kerberos
    message involving PKINIT extensions will be broken in transit.  In
    light of the possibility that the Kerberos specification will
    require KDCs to accept requests using TCP as a transport mechanism,
    we make the same recommendation with respect to the PKINIT
    extensions as well.

7.  Bibliography

    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
    (V5).  Request for Comments 1510.

    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
    for Computer Networks, IEEE Communications, 32(9):33-38.  September
    1994.

    [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
    A. Medvinsky, M. Hur.  Public Key Cryptography for Cross-Realm
    Authentication in Kerberos.
    draft-ietf-cat-kerberos-pk-cross-04.txt

    [4] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
    Kerberos.
    draft-ietf-cat-kerberos-anoncred-00.txt

    [5] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
    Tickets for Application Servers (PKTAPP).
    draft-ietf-cat-pktapp-00.txt

    [6] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
    Using Public Key Cryptography.  Symposium On Network and Distributed
    System Security, 1997.

    [7] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
    Protocol.  In Proceedings of the USENIX Workshop on Electronic
    Commerce, July 1995.

    [8] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
    Request for Comments 2246, January 1999.

    [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
    Distributed Systems.  In Proceedings of the 13th International
    Conference on Distributed Computing Systems, May 1993.

    [10] ITU-T (formerly CCITT) Information technology - Open Systems
    Interconnection - The Directory: Authentication Framework
    Recommendation X.509 ISO/IEC 9594-8

    [11] R. Housley. Cryptographic Message Syntax.
    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
    as RFC.

    [12] PKCS #7: Cryptographic Message Syntax Standard,
    An RSA Laboratories Technical Note Version 1.5
    Revised November 1, 1993

    [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
    Security, Inc. A Description of the RC2(r) Encryption Algorithm
    March 1998.
    Request for Comments 2268.

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

    [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
    Key Infrastructure, Certificate and CRL Profile, January 1999.
    Request for Comments 2459.

    [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
    Specifications, October 1998.  Request for Comments 2437.

    [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
    Version 2 Certificate Handling, March 1998.  Request for
    Comments 2312.

    [18] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
    Protocol (v3), December 1997.  Request for Comments 2251.

8.  Acknowledgements

    Some of the ideas on which this proposal is based arose during
    discussions over several years between members of the SAAG, the IETF
    CAT working group, and the PSRG, regarding integration of Kerberos
    and SPX.  Some ideas have also been drawn from the DASS system.
    These changes are by no means endorsed by these groups.  This is an
    attempt to revive some of the goals of those groups, and this
    proposal approaches those goals primarily from the Kerberos
    perspective.  Lastly, comments from groups working on similar ideas
    in DCE have been invaluable.

9.  Expiration Date

    This draft expires April 30, 2000.

10. Authors

    Brian Tung
    Clifford Neuman
    USC Information Sciences Institute
    4676 Admiralty Way Suite 1001
    Marina del Rey CA 90292-6695
    Phone: +1 310 822 1511
    E-mail: {brian, bcn}@isi.edu

    Matthew Hur
    CyberSafe Corporation
    1605 NW Sammamish Road
    Issaquah WA 98027-5378
    Phone: +1 425 391 6000
    E-mail: matt.hur@cybersafe.com

    Ari Medvinsky
    Excite
    555 Broadway
    Redwood City, CA 94063
    Phone +1 650 569 2119
    E-mail: amedvins@excitecorp.com

    Sasha Medvinsky
    General Instrument
    6450 Sequence Drive
    San Diego, CA 92121
    Phone +1 619 404 2825
    E-mail: smedvinsky@gi.com

    John Wray
    Iris Associates, Inc.
    5 Technology Park Dr.
    Westford, MA 01886
    E-mail: John_Wray@iris.com

    Jonathan Trostle
    170 W. Tasman Dr.
    San Jose, CA 95134
    E-mail: jtrostle@cisco.com