PKINIT specs, draft 9 and final standard

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@20859 dc483132-0cff-0310-8789-dd5450dbe970

2 files changed, 1247 insertions, 0 deletions

diff --git a/doc/krb5-protocol/draft-ietf-cat-kerberos-pk-init-09.txt b/doc/krb5-protocol/draft-ietf-cat-kerberos-pk-init-09.txt
new file mode 100644
index 000000000..748f08954
--- /dev/null
+++ b/doc/krb5-protocol/draft-ietf-cat-kerberos-pk-init-09.txt
@@ -0,0 +1,908 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-09.txt                   Clifford Neuman
+Updates: RFC 1510                                                    ISI
+expires December 1, 1999                                     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-09.txt, and expires December 1,
+    1999.  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 Diffie-Hellman keys in combination with digital
+    signature keys as the primary, required mechanism.  It also allows
+    for the use of RSA keys.  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 a request 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.
+
+    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 an X.500 name as a
+    Realm.  In these cases, the realm will be represented using a
+    different style, specified in RFC 1510 with the following example:
+
+        NAMETYPE:rest/of.name=without-restrictions
+
+    For a realm derived from an X.500 name, NAMETYPE will have the value
+    X500-RFC2253.  The full realm name will appear as follows:
+
+        X500-RFC2253:RFC2253Encode(DistinguishedName)
+
+    where DistinguishedName is an X.500 name, and RFC2253Encode is a
+    readable UTF encoding of an X.500 name, as defined by
+    RFC 2253 [14] (part of LDAPv3).
+
+    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, PKINIT may require the encoding of an X.500 name as a
+    PrincipalName.  In these cases, the name-type of the principal name
+    shall be set to KRB_NT-X500-PRINCIPAL.  This new name type is
+    defined as:
+
+        KRB_NT_X500_PRINCIPAL    6
+
+    The name-string shall be set as follows:
+
+        RFC2253Encode(DistinguishedName)
+
+    as described above.
+
+    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.
+
+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.
+
+    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.
+
+    It is assumed that all public keys are signed by some certification
+    authority (CA).  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;
+                                    -- must be accompanied by
+                                    -- a single trustedCertifier
+        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 OPTIONAL
+                                  -- 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
+      enable static-ephemeral Diffie-Hellman mode for the reply.  As
+      another example, the client may place an RSA encryption
+      certificate in this field.
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- if client is using Diffie-Hellman
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        kdcName                 [0] PrincipalName,
+        kdcRealm                [1] Realm,
+        cusec                   [2] INTEGER,
+                                    -- for replay prevention
+        ctime                   [3] KerberosTime,
+                                    -- for replay prevention
+        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,
+    to bind the request and response.  The PKAuthenticator is signed
+    with the private key corresponding to the public key in the
+    certificate found in userCert (or cached by the KDC).
+
+    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.
+
+    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 the signature on one of the certificates in the client's chain
+    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
+
+        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, the KDC returns an
+    error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation
+    status is unavailable, the KDC returns an error of type
+    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.
+
+    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 a Kerberos name in an extension
+            field, and local KDC policy allows, 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 shall be the name of the
+            certification authority that issued the user's certificate.
+
+    The KDC encrypts the reply not with the user's long-term key, but
+    with a random key generated only for this particular response.  This
+    random key is sealed in the preauthentication field:
+
+    PA-PK-AS-REP ::= CHOICE {
+                            -- PA TYPE 15
+        dhSignedData       [0] SignedData,
+                            -- Defined in CMS and used only with
+                            -- Diffie-Helman key exchange
+                            -- 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.
+
+    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.
+
+    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
+    }
+
+    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 essentially a separate realm, the name of each
+    certifier 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 must bind the public key to a name derivable
+    from the name of the realm for that KDC.  X.509 certificates shall
+    contain the principal name of the KDC 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 define in RFC 1510
+          principalName   [1] PrincipalName,
+                              -- as define 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.
+
+    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 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.
+
+3.2.2. 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.
+
+    [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
+
+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 December 1, 1999.
+
+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
diff --git a/doc/krb5-protocol/rfc4557.txt b/doc/krb5-protocol/rfc4557.txt
new file mode 100644
index 000000000..fe9a8810d
--- /dev/null
+++ b/doc/krb5-protocol/rfc4557.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                             L. Zhu
+Request for Comments: 4557                                 K. Jaganathan
+Category: Standards Track                          Microsoft Corporation
+                                                             N. Williams
+                                                        Sun Microsystems
+                                                               June 2006
+
+
+         Online Certificate Status Protocol (OCSP) Support for
+                      Public Key Cryptography for
+              Initial Authentication in Kerberos (PKINIT)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines a mechanism to enable in-band transmission of
+   Online Certificate Status Protocol (OCSP) responses in the Kerberos
+   network authentication protocol.  These responses are used to verify
+   the validity of the certificates used in Public Key Cryptography for
+   Initial Authentication in Kerberos (PKINIT), which is the Kerberos
+   Version 5 extension that provides for the use of public key
+   cryptography.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................2
+   3. Message Definition ..............................................2
+   4. Security Considerations .........................................3
+   5. Acknowledgements ................................................4
+   6. References ......................................................4
+      6.1. Normative References .......................................4
+      6.2. Informative References .....................................4
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 1]
+
+RFC 4557                OCSP Support for PKINIT                June 2006
+
+
+1.  Introduction
+
+   Online Certificate Status Protocol (OCSP) [RFC2560] enables
+   applications to obtain timely information regarding the revocation
+   status of a certificate.  Because OCSP responses are well bounded and
+   small in size, constrained clients may wish to use OCSP to check the
+   validity of the certificates for Kerberos Key Distribution Center
+   (KDC) in order to avoid transmission of large Certificate Revocation
+   Lists (CRLs) and therefore save bandwidth on constrained networks
+   [OCSP-PROFILE].
+
+   This document defines a pre-authentication type [RFC4120], where the
+   client and the KDC MAY piggyback OCSP responses for certificates used
+   in authentication exchanges, as defined in [RFC4556].
+
+   By using this OPTIONAL extension, PKINIT clients and the KDC can
+   maximize the reuse of cached OCSP responses.
+
+2.  Conventions Used in This Document
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in [RFC2119].
+
+3.  Message Definition
+
+   A pre-authentication type identifier is defined for this mechanism:
+
+              PA-PK-OCSP-RESPONSE              18
+
+   The corresponding padata-value field [RFC4120] contains the DER [X60]
+   encoding of the following ASN.1 type:
+
+          PKOcspData ::= SEQUENCE OF OcspResponse
+                         -- If more than one OcspResponse is
+                         -- included, the first OcspResponse
+                         -- MUST contain the OCSP response
+                         -- for the signer's certificate.
+                         -- The signer refers to the client for
+                         -- AS-REQ, and the KDC for the AS-REP,
+                         -- respectively.
+
+          OcspResponse ::= OCTET STRING
+                         -- Contains a complete OCSP response,
+                         -- as defined in [RFC2560].
+
+   The client MAY send OCSP responses for certificates used in PA-PK-
+   AS-REQ [RFC4556] via a PA-PK-OCSP-RESPONSE.
+
+
+
+Zhu, et al.                 Standards Track                     [Page 2]
+
+RFC 4557                OCSP Support for PKINIT                June 2006
+
+
+   The KDC that receives a PA-PK-OCSP-RESPONSE SHOULD send a PA-PK-
+   OCSP-RESPONSE containing OCSP responses for certificates used in the
+   KDC's PA-PK-AS-REP.  The client can request a PA-PK-OCSP-RESPONSE by
+   using a PKOcspData containing an empty sequence.
+
+   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
+   PA-PK-OCSP-RESPONSE from the client.
+
+   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
+   certificates used in PA-PK-AS-REP [RFC4556].
+
+   Note the lack of integrity protection for the empty or missing OCSP
+   response; lack of an expected OCSP response from the KDC for the
+   KDC's certificates SHOULD be treated as an error by the client,
+   unless it is configured otherwise.
+
+   When using OCSP, the response is signed by the OCSP server, which is
+   trusted by the receiver.  Depending on local policy, further
+   verification of the validity of the OCSP servers may be needed
+
+   The client and the KDC SHOULD ignore invalid OCSP responses received
+   via this mechanism, and they MAY implement CRL processing logic as a
+   fall-back position, if the OCSP responses received via this mechanism
+   alone are not sufficient for the verification of certificate
+   validity.  The client and/or the KDC MAY ignore a valid OCSP response
+   and perform its own revocation status verification independently.
+
+4.  Security Considerations
+
+   The pre-authentication data in this document do not actually
+   authenticate any principals, but are designed to be used in
+   conjunction with PKINIT.
+
+   There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
+   data and PKINIT pre-authentication data other than a given OCSP
+   response corresponding to a certificate used in a PKINIT pre-
+   authentication data element.  Attacks involving removal or
+   replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
+   are, at worst, downgrade attacks, where a PKINIT client or KDC would
+   proceed without use of CRLs or OCSP for certificate validation, or
+   denial-of-service attacks, where a PKINIT client or KDC that cannot
+   validate the other's certificate without an accompanying OCSP
+   response might reject the AS exchange or might have to download very
+   large CRLs in order to continue.  Kerberos V does not protect against
+   denial-of-service attacks; therefore, the denial-of-service aspect of
+   these attacks is acceptable.
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 3]
+
+RFC 4557                OCSP Support for PKINIT                June 2006
+
+
+   If a PKINIT client or KDC cannot validate certificates without the
+   aid of a valid PA-PK-OCSP-RESPONSE, then it SHOULD fail the AS
+   exchange, possibly according to local configuration.
+
+5.  Acknowledgements
+
+   This document was based on conversations among the authors, Jeffrey
+   Altman, Sam Hartman, Martin Rex, and other members of the Kerberos
+   working group.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2560]      Myers, M., Ankney, R., Malpani, A., Galperin, S., and
+                  C. Adams, "X.509 Internet Public Key Infrastructure
+                  Online Certificate Status Protocol - OCSP", RFC 2560,
+                  June 1999.
+
+   [RFC4120]      Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+                  Kerberos Network Authentication Service (V5)", RFC
+                  4120, July 2005.
+
+   [RFC4556]      Zhu, L. and B. Tung, "Public Key Cryptography for
+                  Initial Authentication in Kerberos (PKINIT)", RFC
+                  4556, June 2006.
+
+   [X690]         ASN.1 encoding rules: Specification of Basic Encoding
+                  Rules (BER), Canonical Encoding Rules (CER) and
+                  Distinguished Encoding Rules (DER), ITU-T
+                  Recommendation X.690 (1997) | ISO/IEC International
+                  Standard 8825-1:1998.
+
+6.2.  Informative References
+
+   [OCSP-PROFILE] Deacon, A. and R. Hurst, "Lightweight OCSP Profile for
+                  High Volume Environments", Work in Progress, May 2006.
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 4]
+
+RFC 4557                OCSP Support for PKINIT                June 2006
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: karthikj@microsoft.com
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 5]
+
+RFC 4557                OCSP Support for PKINIT                June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 6]
+