Subject: retry: PKINIT

From: Brian Tung <[email-masked]>
Date: Mon, 17 Dec 2001 11:39:33 -0800

As mentioned in Thursday's meeting, this is the version that is intended
for submission for working group last call.  It is identical to the
altered pk-init-15.txt version that was sent to the group (but not to
the I-D server) a couple of weeks ago, with the following two changes
discussed in the meeting:

    * As proposed by Francois Leclerc, and as agreed upon by the group,
      the required signature algorithm SHA1+DSA is replaced by SHA1+RSA.
      This is changed both in the Required Algorithms section and in
      the Introduction.

    * As mentioned by Mike Thomas, PKINIT lacks a "return routability
      test," making it vulnerable to certain crypto DoS attacks.  As
      agreed upon in the meeting, this possibility is mentioned (without
      further elaboration) in the Security Considerations section.

Brian Tung <[email-masked]>

*****

INTERNET-DRAFT                                                Brian Tung
draft-ietf-cat-kerberos-pk-init-16.txt                   Clifford Neuman
Updates: RFC 1510bis                                             USC/ISI
expires June 25, 2002                                        Matthew Hur
                                                                   Cisco
                                                           Ari Medvinsky
                                                          Keen.com, Inc.
                                                         Sasha Medvinsky
                                                                Motorola
                                                               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-16.txt, and expires June 25, 2002.
    Please send comments to the authors.

1.  Abstract

    This document defines extensions (PKINIT) to the Kerberos protocol
    specification (RFC 1510bis [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 RSA keys as the primary, required mechanism.  Note
    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
    symmetric key, a public key, or both.

    The PKINIT specification may also be used as a building block for
    other specifications.  PKINIT may be utilized to establish
    inter-realm keys for the purposes of issuing cross-realm service
    tickets.  It may also be used to issue anonymous Kerberos tickets
    using the Diffie-Hellman option.  Efforts are under way to draft
    specifications for these two application protocols.

    Additionally, the PKINIT specification may be used for direct peer
    to peer authentication without contacting a central KDC. This
    application of PKINIT 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 [5] 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 [6]).

3.  Proposed Extensions

    This section describes extensions to RFC 1510bis 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 1510bis 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).  The
    above encryption types are utilized only within CMS structures
    within the PKINIT preauthentication fields. Their use within
    the Kerberos EncryptedData structure is unspecified.

    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 realm it will be represented using the "Other" form of the realm
    name as specified in the naming constraints section of RFC 1510bis.
    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 [11] (part of LDAPv3 [15]).

    Each component of a DistinguishedName is called a
    RelativeDistinguishedName, where a RelativeDistinguishedName is a
    SET OF AttributeTypeAndValue.  RFC 2253 does not specify the order
    in which to encode the elements of the RelativeDistinguishedName and
    so to ensure that this encoding is unique, we add the following rule
    to those specified by RFC 2253:
     
	When converting a multi-valued RelativeDistinguishedName
        to a string, the output consists of the string encodings
        of each AttributeTypeAndValue, in the same order as
	specified by the DER encoding.    

    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 MUST be set to KRB_NT-X500-PRINCIPAL.  This new
    name type is defined in RFC 1510bis as:

        KRB_NT_X500_PRINCIPAL    6

    For this type, the name-string MUST be set as follows:

        RFC2253Encode(DistinguishedName)

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

    Note that the same string may be represented using several different
    ASN.1 data types.  As the result, the reverse conversion from an
    RFC2253-encoded principal name back to an X.500 name may not be
    unique and may result in an X.500 name that is not the same as the
    original X.500 name found in the client certificate.

    RFC 1510bis describes an alternate encoding of an X.500 name into a
    realm name.  However, as described in RFC 1510bis, the alternate
    encoding does not guarantee a unique mapping from a
    DistinguishedName inside a certificate into a realm name and
    similarly cannot be used to produce a unique principal name.  PKINIT
    therefore uses an RFC 2253-based name mapping approach, as specified
    above.

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

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

    The following rules relate to the the matching of PrincipalNames
    with regard to the PKI name constraints for CAs as laid out in RFC
    2459 [12].  In order to be regarded as a match (for permitted and
    excluded name trees), the following MUST be satisfied.

        1.  If the constraint is given as a user plus realm name, or
            as a client principal name plus realm name (as specified in
            RFC 1510bis), the realm name MUST be valid (see 2.a-d below)
            and the match MUST be exact, byte for byte.

        2.  If the constraint is given only as a realm name, matching
            depends on the type of the realm:

            a.  If the realm contains a colon (':') before any equal
                sign ('='), it is treated as a realm of type Other,
                and MUST match exactly, byte for byte.

            b.  Otherwise, if the realm name conforms to rules regarding
                the format of DNS names, it is considered a realm name of
                type Domain.  The constraint may be given as a realm
                name 'FOO.BAR', which matches any PrincipalName within
                the realm 'FOO.BAR' but not those in subrealms such as
                'CAR.FOO.BAR'.  A constraint of the form '.FOO.BAR'
                matches PrincipalNames in subrealms of the form
                'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.

            c.  Otherwise, the realm name is invalid and does not match
                under any conditions.

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 is produced from the agreed
    bit string as follows:

        * Truncate the bit string to the required length.
        * Apply the specific cryptosystem's random-to-key function.

    Appropriate key constraints for each valid cryptosystem are given
    in RFC 1510bis.

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 [8] and
    in [12] are used with PKINIT:

    sha-1WithRSAEncryption (RSA with SHA1)
    md5WithRSAEncryption   (RSA with MD5)
    id-dsa-with-sha1       (DSA 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 [12].

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 [13].
    Currently, only PKCS#1 v1.5 is specified by CMS [8], 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 [8].

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 1510bis, 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] ContentInfo,
                                    -- Defined in CMS [8];
                                    -- SignedData OID is {pkcs7 2}
                                    -- AuthPack (below) defines the
                                    -- data that is signed.
        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
                                    -- This is a list of CAs that the
                                    -- client trusts and that certify
                                    -- KDCs.
        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
                                    -- As defined in CMS [8];
                                    -- 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
    }

    The type of the ContentInfo in the signedAuthPack is SignedData.
    Its usage is as follows:

        The SignedData data type is specified in the Cryptographic
        Message Syntax, a product of the S/MIME working group of the
        IETF.  The following describes how to fill in the fields of
        this data:

        1.  The encapContentInfo field MUST contain the PKAuthenticator
            and, optionally, the client's Diffie Hellman public value.

            a.  The eContentType field MUST contain the OID value for
                pkauthdata: iso (1) org (3) dod (6) internet (1)
                security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)

            b.  The eContent field is data of the type AuthPack (below).

        2.  The signerInfos field contains the signature of AuthPack.

        3.  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 certificate
            chains 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.

        4.  When a DH key is being used, the public exponent is provided
            in the subjectPublicKey field of the SubjectPublicKeyInfo and
            the DH parameters are supplied as a DomainParameters in the
            AlgorithmIdentitfier parameters.  The DH paramters SHOULD be
            chosen from the First and Second defined Oakley Groups [The
            Internet Key Exchange (IKE) RFC-2409], if a server will not
            accept either of these groups, it will respond with a krb-
            error of KDC_ERR_KEY_TOO_WEAK and the e_data will contain a
            DomainParameters with appropriate parameters for the client
            to use.

        5.  The KDC may wish to use cached Diffie-Hellman parameters
            (see Section 3.2.2, KDC Response).  To indicate acceptance
            of cached parameters, the client sends zero in the nonce
            field of the PKAuthenticator.  Zero is not a valid value
            for this field under any other circumstances.  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.  (With
            a zero nonce, message binding is performed using the nonce
            in the main request, which must be encrypted using the
            encapsulated reply key.)

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

    PKAuthenticator ::= SEQUENCE {
        cusec                   [0] INTEGER,
                                    -- for replay prevention as in RFC 1510bis
        ctime                   [1] KerberosTime,
                                    -- for replay prevention as in RFC 1510bis
        nonce                   [2] INTEGER,
                                    -- zero only if client will accept
                                    -- cached DH parameters from KDC;
                                    -- must be non-zero otherwise
        pachecksum              [3] Checksum
                                    -- Checksum over KDC-REQ-BODY
                                    -- Defined by Kerberos spec;
				    -- must be unkeyed, e.g. sha1 or rsa-md5
    }

    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 [7]

    AlgorithmIdentifier ::= SEQUENCE {
        algorithm                   OBJECT IDENTIFIER,
                                    -- for dhKeyAgreement, this is
                                    -- { iso (1) member-body (2) US (840)
                                    -- ansi-x942(10046) number-type(2) 1 }
                                    -- from RFC 2459 [12]
        parameters                  ANY DEFINED by algorithm OPTIONAL
                                    -- for dhKeyAgreement, this is
                                    -- DomainParameters
    }   -- as specified by the X.509 recommendation [7]

    DomainParameters ::= SEQUENCE {
        p                           INTEGER, -- odd prime, p=jq +1
        g                           INTEGER, -- generator, g
        q                           INTEGER, -- factor of p-1
        j                           INTEGER OPTIONAL, -- subgroup factor
        validationParms             ValidationParms OPTIONAL
    }   -- as defined in RFC 2459 [12]

    ValidationParms ::= SEQUENCE {
        seed                        BIT STRING,
                                    -- seed for the system parameter
                                    -- generation process
        pgenCounter                 INTEGER
                                    -- integer value output as part
                                    -- of the of the system parameter
                                    -- prime generation process
    }   -- as defined in RFC 2459 [12]

    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 1510bis revisions as a SEQUENCE of TypedData:

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

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

    The PKAuthenticator carries information to foil replay attacks, to
    bind the pre-authentication data to the KDC-REQ-BODY, 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.

    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.

    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.  One specific case of this is
    the presence or absence of an Enhanced Key Usage (EKU) OID within
    the certificate extensions.  The rules regarding acceptability of
    an EKU sequence (or the absence of any sequence) are a matter of
    local policy.  For the benefit of implementers, we define a PKINIT
    EKU OID as the following: iso (1) org (3) dod (6) internet (1)
    security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).

    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, with an e-data containing a structure of
    type DomainParameters with appropriate DH parameters for the client
    to retry the request.  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
    RFC 1510bis.

    Assuming no errors, the KDC replies as per RFC 1510bis, 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
            as necessary (e.g., as per RFC 2253 for X.500 names).  In
            this case the realm in the ticket MUST be the name of the
            certifier that issued the user's certificate.

    Note that a principal name may be carried in the subjectAltName
    field of a certificate. This name may be mapped to a principal
    record in a security database based on local policy, for example
    the subjectAltName 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 [14], may utilize the email address.  If the KDC
    is presented with an 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 mapped
    according to local policy.  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 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] ContentInfo,
                            -- Defined in CMS [8] and used only with
                            -- Diffie-Hellman key exchange (if the
                            -- client public value was present in the
                            -- request).
                            -- SignedData OID is {pkcs7 2}
                            -- This choice MUST be supported
                            -- by compliant implementations.
        encKeyPack         [1] ContentInfo
                            -- Defined in CMS [8].
                            -- The temporary key is encrypted
                            -- using the client public key
                            -- key.
                            -- EnvelopedData OID is {pkcs7 3}
                            -- SignedReplyKeyPack, encrypted
                            -- with the temporary key, is also
                            -- included.
    }

    The type of the ContentInfo in the dhSignedData is SignedData.
    Its usage is as follows:

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

        1.  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.

        2.  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.

            a.  For example, if the reply key is DES, N=64 bits, where
                some of the bits are replaced with parity bits, according
                to FIPS PUB 74.

            b.  As another example, 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.

        3.  The encapContentInfo field MUST contain the KdcDHKeyInfo as
            defined below.

            a.  The eContentType field MUST contain the OID value for
                pkdhkeydata: iso (1) org (3) dod (6) internet (1)
                security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)

            b.  The eContent field is data of the type KdcDHKeyInfo
                (below).

        4.  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).

        5.  The signerInfos field is a SET that MUST contain at least
            one member, since it contains the actual signature.

        6.  If the client indicated acceptance of cached Diffie-Hellman
            parameters from the KDC, and the KDC supports such an option
            (for performance reasons), the KDC should return a zero in
            the nonce field and include the expiration time of the
            parameters in the dhKeyExpiration field.  If this time is
            exceeded, the client SHOULD NOT use the reply.  If the time
            is absent, the client SHOULD NOT use the reply and MAY
            resubmit a request with a non-zero nonce (thus indicating
            non-acceptance of cached Diffie-Hellman parameters).  As
            indicated above in Section 3.2.1, Client Request, when the
            KDC uses cached parameters, the client and the KDC MUST
            perform key derivation (for the appropriate cryptosystem)
            on the resulting encryption key, as specified in RFC 1510bis.

    KdcDHKeyInfo ::= SEQUENCE {
                              -- used only when utilizing Diffie-Hellman
      subjectPublicKey      [0] BIT STRING,
                                -- Equals public exponent (g^a mod p)
                                -- INTEGER encoded as payload of
                                -- BIT STRING
      nonce                 [1] INTEGER,
                                -- Binds response to the request
                                -- Exception: Set to zero when KDC
                                -- is using a cached DH value
      dhKeyExpiration       [2] KerberosTime OPTIONAL
                                -- Expiration time for KDC's cached
                                -- DH value
    }

    The type of the ContentInfo in the encKeyPack is EnvelopedData.  Its
    usage is as follows:

        The EnvelopedData data type is specified in the Cryptographic
        Message Syntax, a product of the S/MIME working group of the
        IETF.  It contains a temporary key encrypted with the PKINIT
        client's public key.  It also contains a signed and encrypted
        reply key.

        1.  The originatorInfo field is not required, since that
            information may be presented in the signedData structure
            that is encrypted within the encryptedContentInfo field.

        2.  The optional unprotectedAttrs field is not required for
            PKINIT.

        3.  The recipientInfos field is a SET which MUST contain exactly
            one member of the KeyTransRecipientInfo type for encryption
            with a public key.

            a.  The encryptedKey field (in KeyTransRecipientInfo)
                contains the temporary key which is encrypted with the
                PKINIT client's public key.

        4.  The encryptedContentInfo field contains the signed and
            encrypted reply key.

            a.  The contentType field MUST contain the OID value for
                id-signedData: iso (1) member-body (2) us (840)
                rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)

            b.  The encryptedContent field is encrypted data of the CMS
                type signedData as specified below.

                i.  The encapContentInfo field MUST contains the
                    ReplyKeyPack.

                    * The eContentType field MUST contain the OID value
                      for pkrkeydata: iso (1) org (3) dod (6) internet (1)
                      security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3)

                    * The eContent field is data of the type ReplyKeyPack
                      (below).

                ii.  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).

                iii.  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,
                                 -- from RFC 1510bis
                                 -- 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
    }

3.2.2.1. Use of transited Field

    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.

3.2.2.2. Kerberos Names in Certificates

    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 MUST contain the principal name of the KDC (defined in
    RFC 1510bis) 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] OtherName,
            ...
        }

        OtherName ::= SEQUENCE {
            type-id         OBJECT IDENTIFIER,
            value           [0] EXPLICIT ANY DEFINED BY type-id
        }

    For the purpose of specifying a Kerberos principal name, the value
    in OtherName MUST be a KerberosName, defined as follows:

        KerberosName ::= SEQUENCE {
            realm           [0] Realm,
            principalName   [1] PrincipalName
        }

    This specific syntax is identified within subjectAltName by setting
    the type-id in OtherName 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.

    Note that the KDC's principal name has the instance equal to the
    realm, and those fields should be appropriately set in the realm
    and principalName fields of the KerberosName.  This is the case
    even when obtaining a cross-realm ticket using PKINIT.

3.2.3. Client Extraction of Reply

    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 1510bis.

3.2.4. 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 RSA for signatures
    * SHA1 digest for the Checksum in the PKAuthenticator
        * using Kerberos checksum type 'sha1'
    * 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 extends the cross-realm model to the public
    key infrastructure.  Anyone using PKINIT must be aware of how the
    certification infrastructure they are linking to works.

    Also, as in standard Kerberos, PKINIT presents the possibility of
    interactions between different cryptosystems of varying strengths,
    and this now includes public-key cryptosystems.  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, may be inappropriate.

    Care should be taken in how certificates are choosen for the purposes
    of authentication using PKINIT. Some local policies require that key
    escrow be applied for certain certificate types. People deploying
    PKINIT should be aware of the implications of using certificates that
    have escrowed keys for the purposes of authentication.

    As described in Section 3.2, PKINIT allows for the caching of the
    Diffie-Hellman parameters on the KDC side, for performance reasons.
    For similar reasons, the signed data in this case does not vary from
    message to message, until the cached parameters expire.  Because of
    the persistence of these parameters, the client and the KDC are to
    use the appropriate key derivation measures (as described in RFC
    1510bis) when using cached DH parameters.

    PKINIT does not provide for a "return routability test" to prevent
    attackers from mounting a denial of service attack on the KDC by
    causing it to perform needless expensive cryptographic operations.
    Strictly speaking, this is also true of base Kerberos, although the
    potential cost is not as great in base Kerberos, because it does
    not make use of public key cryptography.

    Lastly, PKINIT calls for randomly generated keys for conventional
    cryptosystems.  Many such systems contain systematically "weak"
    keys.  For recommendations regarding these weak keys, see RFC
    1510bis.

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] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
    Using Public Key Cryptography.  Symposium On Network and Distributed
    System Security, 1997.

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

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

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

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

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

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

    [10] 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.

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

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

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

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

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

    [16] ITU-T (formerly CCITT) Information Processing Systems - Open
    Systems Interconnection - Specification of Abstract Syntax Notation
    One (ASN.1) Rec. X.680 ISO/IEC 8824-1

    [17] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
    Laboratories Technical Note, Version 1.4, Revised November 1, 1993.

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 June 25, 2002.

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, [email-masked]

    Matthew Hur
    Cisco Systems
    2901 Third Avenue
    Seattle WA 98121
    Phone: (206) 256-3197
    E-Mail: [email-masked]

    Ari Medvinsky
    Keen.com, Inc.
    150 Independence Drive
    Menlo Park CA 94025
    Phone: +1 650 289 3134
    E-mail: [email-masked]

    Sasha Medvinsky
    Motorola
    6450 Sequence Drive
    San Diego, CA 92121
    +1 858 404 2367
    E-mail: [email-masked]

    John Wray
    Iris Associates, Inc.
    5 Technology Park Dr.
    Westford, MA 01886
    E-mail: [email-masked]

    Jonathan Trostle
    Cisco Systems
    170 W. Tasman Dr.
    San Jose, CA 95134
    E-mail: [email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Mon, 17 Dec 2001 12:19:20 -0800 (PST)

>       further elaboration) in the Security Considerations section.

   I guess I have to ask, considering all of the 
   hand-wringing with IKE about this attack, why
   do we believe that a Kerberos KDC wouldn't be
   a target? Indeed, many Kerberos haters like to
   point out that centralized architectures are
   choice targets for attackers.

   Now, it's possible to factor this into
   revisions as a general feature, but it's really
   PKINIT/PKCROSS which bring this problem to the
   fore.

	Mike (sorry for not being there)

---

From: Sam Hartman <[email-masked]>
Date: 18 Dec 2001 10:33:14 -0500

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Michael>    I guess I have to ask, considering all of the
    Michael> hand-wringing with IKE about this attack, why do we
    Michael> believe that a Kerberos KDC wouldn't be a target? Indeed,
    Michael> many Kerberos haters like to point out that centralized
    Michael> architectures are choice targets for attackers.

    Michael>    Now, it's possible to factor this into revisions as a
    Michael> general feature, but it's really PKINIT/PKCROSS which
    Michael> bring this problem to the fore.

How would you propose to solve this in revisions?  Even if we don't
want to solve it there I need to make sure that the extensibility
framework is general enough to handle it.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 18 Dec 2001 07:57:22 -0800 (PST)

> framework is general enough to handle it.

Two places, I think, would need to be modified. In
general you could use a SYN-COOKIES like approach
to have the KDC generate a hash of the IP address,
etc, when it feels like it's under attack. This
would be placed in a new Krb-err. It probably
means a new extension to krb-err's since I don't
think the data field is appropriate, but that's
debatable I guess. When the client receives one of
these krb-err's, it just places the cookie into
the AS-REQ as probably a new pre-auth field. If
the under-attack KDC sees this pre-auth field, it
hashes the goodies again and compares it to the
presented hash and admits only ones that are legit
to the next stage of processing.

If the extensibility framework can handle this,
I'm totally cool on moving forward with PKINIT
and/or revisions. If there's interest, I could
write a short draft to make this a concrete
proposal.

		Mike

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Dec 2001 11:08:02 -0500

Correct me if I'm wrong, but a "return routability test" would require
an additional round-trip to have the client prove it can be routed back
to:

client->service pre-req
service->client pre-req+nonce
client->service req + (nonce + 1)
service->client rep

Yes? The idea being to prevent spoofed requests from causing services to
spend many cycles on crypto only to come up with decrypt integrity check
failures, pre-auth failures, etc...

On a public Internet a return routability test might even be necessary.
Yes/no?

Cheers,

Nico

--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 18 Dec 2001 08:14:19 -0800 (PST)

Nicolas Williams writes:
 > Yes? 

   Yes. Hence you only want to do this if you suspect
   you're under attack.

> The idea being to prevent spoofed requests from causing services to

   Yup.
 
 > On a public Internet a return routability test might even be necessary.

   On any old internet that you feel is vulnerable to
   source spoofing, yes.

	  Mike

---

From: Sam Hartman <[email-masked]>
Date: 18 Dec 2001 11:29:52 -0500

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Michael> Two places, I think, would need to be modified. In
    Michael> general you could use a SYN-COOKIES like approach to have
    Michael> the KDC generate a hash of the IP address, etc, when it
    Michael> feels like it's under attack. This would be placed in a
    Michael> new Krb-err. It probably means a new extension to
    Michael> krb-err's since I don't think the data field is
    Michael> appropriate, but that's debatable I guess. When the
    Michael> client receives one of these krb-err's, it just places
    Michael> the cookie into the AS-REQ as probably a new pre-auth
    Michael> field. If the under-attack KDC sees this pre-auth field,
    Michael> it hashes the goodies again and compares it to the
    Michael> presented hash and admits only ones that are legit to the
    Michael> next stage of processing.

OK, we can't really do this in revisions unless we are willing to
sacrifice interop with existing clients while we are under attack.  If
we are willing to do that we can stick it in revisions with the new
framework.

If we don't want to put it in revisions it should go in pkinit.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Dec 2001 11:23:25 -0500

How about it then? Could an error be added to indicate a request for the
client to retry with a service-provided nonce (+1)?

So the requests would need a new OPTIONAL field (larger than 32 bits,
yes?) to carry the nonce+1 and a new error (and OPTIONAL error field?)
would be needed to carry the return routability challenge.

This could probably be used with no problems in the KDC exchanges, but I
don't see how it could be used in the AP exchanges without changes to
the apps (and the GSS-API Kerberos mech spec?).

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 Dec 2001 11:33:40 -0500 (EST)

> write a short draft to make this a concrete

Your proposal talks about adding extensions to KDC-REQ and to KRB-ERROR.
Under the generalized extensibility proposal, it would be possible to do
this now, and if it isn't done now, it would be possible to do it in the
future.  So, it doesn't expose any flaws in that proposal.

However, I'm a little confused about how you propose to handle clients
that don't support the cookies.  Is the under-attack KDC to drop all
requests that don't include a cookie?  If not, how do you distinguish
the attacker's bogus requests from legitimate requests sent by clients
which don't support the cookies?

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Michael Thomas <[email-masked]>
Date: Tue, 18 Dec 2001 09:44:18 -0800 (PST)

> we are willing to do that we can stick it in revisions with the new

Correct. However, there's probably a lot less
reason to require this functionality unless you're
using PKINIT. Indeed, it might be the right thing
to just live with the smaller DoS opportunity
that's currently open with symmetric key Kerberos.

 > If we don't want to put it in revisions it should go in pkinit.
 
Perhaps. It's not clear that it couldn't be a
separate draft though and deal with this more on a
system level (ie, if you want to be part of my
realm, you must support rfc xxx).

	   Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 18 Dec 2001 11:36:45 -0800 (PST)

> the apps (and the GSS-API Kerberos mech spec?).

   I don't think the threat is nearly as great with
   AP-REQ/AP-REP or TGS-REQ/TGS-REP. If this only 
   covered PKINIT/PKCROSS AS-REQ's, I think that would
   sufficient.

		Mike

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Dec 2001 15:08:20 -0500

>    covered PKINIT/PKCROSS AS-REQ's, I think that would

Is the threat lower with AP exchanges because symmetric key crypto uses
fewer cycles than public crypto and the latter is not used in AP
exchanges?

Is there any empirical study of the effectiveness of cycle-wasting DoS
attacks against symmetric key crypto versu public crypto?

Mind you. I'm inclined to agree; in fact, I do agree :)

Cheers,

Nico

---

From: Michael Thomas <[email-masked]>
Date: Tue, 18 Dec 2001 13:36:13 -0800 (PST)

> which don't support the cookies?

There is a clear DoS attack against clients
unaware about this extension, yes. However, this
is primarily an attack that can be perpetrated
when using PKINIT/PKCROSS and only then while the
KDC perceives itself to be under attack. Is this a
credible enough attack which outweighes the CPU
slagging attack against a naive PKINIT-capable
KDC? I suspect not. Note that Steve Bellovin just
dredged up a Bugtraq report about an attack
against NT's IKE, so this isn't just academic.

	     Mike

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 Dec 2001 20:13:19 -0500 (EST)

> unaware about this extension, yes. However, this

The DoS attack is to make the KDC think its under attack, at which point
it will refuse to talk to any client that doesn't support this extension.
IMHO that's not much better than an attack which denys service by chewing
up all of the KDC's cycles.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 18 Dec 2001 17:49:22 -0800 (PST)

> up all of the KDC's cycles.

   I disagree. The clients can always implement the 
   extension -- much like when there was a big
   rush to implement SYN-COOKIES. Without this
   sort of protection, both KDC and client would
   be exposed. Ideally, this would be part of
   what's required for PKINIT/PKCROSS, but as I've
   said I think it's acceptible to partition this
   just to help standards inertia.

	   Mike

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 Dec 2001 21:05:23 -0500 (EST)

>    just to help standards inertia.

Even if we don't do this in revisions, I don't think it should be tied to
PKINIT/PKCROSS.  That makes it too likely that people will think of it as
part of those extensions instead of as a generally useful feature.  I
wouldn't object to putting this feature in revisions and making it
recommended-but-not-required.  I would be upset if a KDC implementation
did not allow me to turn it off...

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Dec 2001 09:21:42 -0500

> did not allow me to turn it off...

Sure, but it has to be required for the clients if it is allowed for the
KDCs.

Nico

---

From: Michael Thomas <[email-masked]>
Date: Wed, 19 Dec 2001 08:49:40 -0800 (PST)

> did not allow me to turn it off...

   Sigh. Finding a home at this late date is going
   to involve some sort of compromise. Rather than
   trying to solve that problem right now, maybe we
   should see if there's consensus that it should be
   solved now. If so, a concrete draft may make it
   easier to sort the logistics out.

	     Mike

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Dec 2001 12:34:03 -0500

I'm afraid that adding the return routability test later or with PKINIT
will limit its use such that it can only be used with clients attempting
PKINIT or some pre-auth approved later than revisions.

Adding the return routability now and making support for it a MUST for
clients and a MAY or SHOULD for KDCs would allow its use with all new
clients period.

It seems that all that's needed to implement such a return routability
test would be a new OPTIONAL field for KDC-REQ, a new OPTIONAL field
for KRB-ERROR and a new error number. That and a statement about clients
having to extract this new field from KRB-ERRORs with that new error and
then include that field (+1?) in a retry of the KDC-REQ.

The main complication might be what type and size that field should be.
TCP shows us that 32 bits are not enough for the purpose, but
implementing ASN.1 / large integers is problematic. Perhaps a SEQUENCE
OF Int32 would do.

IMHO this is not hard. The question is: will it slow down revisions?

Can this be offered at the interim meeting, where consensus can be
reached on whether or not to exclude it from revisions?

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Dec 2001 13:21:38 -0500

Hmmm, perhaps the return routability test could be implemented as a
pre-auth required error where the KRB-ERROR indicates that the new
pre-auth type is needed and includes pa-data with the nonce to be
included in the client's KDC-REQ.

The question is: would that conflict with existing pa usage?

Think of a pre-auth required error response to a TGS-REQ and think:
would clients drop the other PA-DATA and replace it with the
routability test PA-DATA?  or would they add the routability test
PA-DATA to the other PA-DATA?

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2001 11:46:50 -0500

Another happy thought occurs: the client too can send a cookie that must
be included, at the very least, in any unatuhenticated KRB-ERROR from
the KDC. This should make KRB-ERROR spoofing much more difficult.

So a two-way return routability test would be a nice option. And the
question I have is: can it be done with new pre-auth types only?

Cheers,

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Dec 2001 11:52:45 -0500 (EST)

> question I have is: can it be done with new pre-auth types only?

It should be doable with new PADATA types, but you have to think of padata
as a typed hole and not just preauth.  The return routability test isn't
preauth, and shouldn't be treated as such.  For example, you shouldn't use
a preauth-required error to initiate the test.  Use a new error code.

---

From: Sam Hartman <[email-masked]>
Date: 20 Dec 2001 11:59:25 -0500

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> On Thu, 20 Dec 2001, Nicolas Williams wrote:
    >> Another happy thought occurs: the client too can send a cookie
    >> that must be included, at the very least, in any
    >> unatuhenticated KRB-ERROR from the KDC. This should make
    >> KRB-ERROR spoofing much more difficult.
    >> 
    >> So a two-way return routability test would be a nice
    >> option. And the question I have is: can it be done with new
    >> pre-auth types only?

    Jeffrey> It should be doable with new PADATA types, but you have

Hmm, it should be doable with the nonce field in the request that we
are adding to krb-error.

    Jeffrey> to think of padata as a typed hole and not just preauth.
    Jeffrey> The return routability test isn't preauth, and shouldn't
    Jeffrey> be treated as such.  For example, you shouldn't use a
    Jeffrey> preauth-required error to initiate the test.  Use a new
    Jeffrey> error code.

Why isn't it preauth?  I was going to make this argument yesterday,
got as far as starting to write the message and realized I had no
justification for why this wasn't a very weak form of preauth.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2001 12:05:16 -0500

> a preauth-required error to initiate the test.  Use a new error code.

If you wish. And that would be a new error code and new optional fields.

But, the way I see it, return-routability-tests-as-pre-auth makes sense
because, though neither party is being authenticated to each other,
something is being proven: routability.

Either way, I was offering the use of pre-auth for this merely as way
to reduce the amount of work to be done on the main part of the
extensibility revisions. And that because there's no other better time
to get a return routability test into Kerberos than with revisions -
do it afterwards and you have to worry about new clients that don't
support this feature.

I'm not attached to using pre-auth or not for this feature.

But then again if it's done as pre-auth then old Kerberos could support
it, paticularly if there are PKINIT implementations based on old
Kerberos waiting in the wings.

The thought of being able to distinguish spoofed KRB-ERRORs from real
KRB-ERRORs without cryptography is appealing. So now I'd definitely
like to see return routability in the revisions - clients should be
required to support it, KDCs should have the option to support it, and
only with new Kerberos.

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2001 12:57:21 -0500

> Hmm, it should be doable with the nonce field in the request that we

I did not see that in the ASN.1 module you posted.

The return routability nonce field should not be an Int32. We should
have learned from TCP that a small and fixed width random ISN integer
makes ISN prediction attacks too easy. Not that KDC exchanges would be
as vulnerable to such attack as TCP - it's a DoS for Kerberos but a
real attack with TCP.

> justification for why this wasn't a very weak form of preauth.

My thoughts exactly, though neither party would be pre-authenticated
with this - the network path would merely be proven.

Cheers,

Nico

---

From: Sam Hartman <[email-masked]>
Date: 20 Dec 2001 13:10:05 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Thu, Dec 20, 2001 at 11:59:25AM -0500, Sam Hartman
    >>  Hmm, it should be doable with the nonce field in the request
    >> that we are adding to krb-error.

    Nicolas> I did not see that in the ASN.1 module you posted.
It wasn't there.   Check the open issues list I posted; it is listed under the fixes section.

    Nicolas> The return routability nonce field should not be an
    Nicolas> Int32. We should have learned from TCP that a small and
    Nicolas> fixed width random ISN integer makes ISN prediction
    Nicolas> attacks too easy. Not that KDC exchanges would be as
    Nicolas> vulnerable to such attack as TCP - it's a DoS for
    Nicolas> Kerberos but a real attack with TCP.

The problem with TCP is that the integers aren't random.  Keep in mind
that a nonce is local to a specific client server and port tripple.

There aren't likely to be too many active requests at any give time.  As such I don't think the TCP problems are likely to happen.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2001 13:21:20 -0500

> It wasn't there.   Check the open issues list I posted; it is listed under the fixes section.

Ok.

> that a nonce is local to a specific client server and port tripple.

Nowadayus folks try to make the ISNs random. They try.

> There aren't likely to be too many active requests at any give time.  As such I don't think the TCP problems are likely to happen.

Well, the Kerberos tuple would be {client, KDC}, and, those the number
of KDC exchanges needed by clients are fewer than the number of TCP
sessions they use, this Kerberos tuple namespace will be smaller than
the TCP tuple namespace because there's no "ports" in the Kerberos
tuple.

So make this nonce big. I know, it'll be a pain for implementors, so
might as well make it an OCTET STRING and treat it as opaque, and not as
as an integer.

Cheers,

Nico

---

From: Sam Hartman <[email-masked]>
Date: 20 Dec 2001 16:36:29 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Nowadayus folks try to make the ISNs random. They try.

No,  they try to make them random within the constraints of the RFC.
    Nicolas> Kerberos tuple namespace will be smaller than the TCP
    Nicolas> tuple namespace because there's no "ports" in the
    Nicolas> Kerberos tuple.

Yes, there is; the client port is important.  The server port is
important as well although in most cases it is 88.

    Nicolas> So make this nonce big. I know, it'll be a pain for
    Nicolas> implementors, so might as well make it an OCTET STRING
    Nicolas> and treat it as opaque, and not as as an integer.

Let's assume it is random.  You have 10 outstanding requests.  In
order to create a DOS you need to pick one of the 10 numbers chosen by
the current requests.  Your probability of success is sufficiently low
that you'll create more of a problem with excess traffic than you do
with load from correct guesses of nonce.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2001 16:49:17 -0500

Ok. Since the attack is merely a DoS with Kerberos it's no big deal.

32 bits it is then, yes?

Nico

---

From: Matt Crawford <[email-masked]>
Date: Thu, 20 Dec 2001 16:45:30 -0600

> Nowadayus folks try to make the ISNs random. They try.

They aren't allowed to be purely random.  They have another
function.  Let's move away from that analogy please.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2001 23:14:56 -0500

> Ok. Since the attack is merely a DoS with Kerberos it's no big deal.

Another thought occurs. Neither side needs to manipulate the nonce from
the other; each side need only be able to copy the nonce encoding from
the other side into their reply. Therefore the nonces in question could
be INTEGER, rather than Int32, thus making the size of these nonces a
non-issue.

And the more I think about it, the more I am convinced that the return
routability tests as pre-auth. That way old Kerberos can take advantage
of it, and so can PKINIT. And it can even be the PKINIT spec that
defines the new pre-auth type(s).

Alternatively, UDP could be deprecated for KDC exchanges; TCP has a
return routability test in the form of its handshake... :) :) :) so that
all that would be needed is a new error message saying "please use TCP
instead" (but, that error message could be spoofed, which is an argument
for sticking with pre-auth data for this).

Cheers - happy holydays,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Dec 2001 00:39:56 -0500

> instead" (but, that error message could be spoofed, which is an argument
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I should go get some sleep now.

Nico