summaryrefslogtreecommitdiff
path: root/doc/standardisation/draft-zhu-pku2u-09.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/standardisation/draft-zhu-pku2u-09.txt')
-rw-r--r--doc/standardisation/draft-zhu-pku2u-09.txt1288
1 files changed, 0 insertions, 1288 deletions
diff --git a/doc/standardisation/draft-zhu-pku2u-09.txt b/doc/standardisation/draft-zhu-pku2u-09.txt
deleted file mode 100644
index e6d1b75e7..000000000
--- a/doc/standardisation/draft-zhu-pku2u-09.txt
+++ /dev/null
@@ -1,1288 +0,0 @@
-
-
-NETWORK WORKING GROUP L. Zhu
-Internet-Draft Microsoft Corporation
-Intended status: Standards Track J. Altman
-Expires: May 7, 2009 Secure Endpoints
- N. Williams
- Sun
- November 3, 2008
-
-
- Public Key Cryptography Based User-to-User Authentication - (PKU2U)
- draft-zhu-pku2u-09
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- 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.
-
- This Internet-Draft will expire on May 7, 2009.
-
-Abstract
-
- This document defines a Generic Security Services Application Program
- Interface (GSS-API) mechanism based on Public Key Infrastructure
- (PKI) - PKU2U. This mechanism is based on Kerberos V messages and the
- Kerberos V GSS-API mechanism, but without requiring a Kerberos Key
- Distribution Center (KDC).
-
-
-
-
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 1]
-
-Internet-Draft PKU2U November 2008
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
- 3. The PKU2U Realm Name . . . . . . . . . . . . . . . . . . . . . 3
- 4. The NULL Principal Name . . . . . . . . . . . . . . . . . . . 4
- 5. PKU2U Principal Naming . . . . . . . . . . . . . . . . . . . . 4
- 5.1. GSS_C_NT_DN . . . . . . . . . . . . . . . . . . . . . . . 6
- 5.2. GSS_C_NT_HOSTNAME . . . . . . . . . . . . . . . . . . . . 6
- 5.3. GSS_C_NT_EMAIL_ADDR . . . . . . . . . . . . . . . . . . . 7
- 5.4. GSS_KRB5_NT_PRINCIPAL_NAME . . . . . . . . . . . . . . . . 7
- 5.5. GSS_C_NT_ANONYMOUS . . . . . . . . . . . . . . . . . . . . 9
- 5.6. GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based
- Principal Names to Acceptor Certificates . . . . . . . . . 9
- 6. The Protocol Description and the Context Establishment
- Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 6.1. Context Token Derived from KRB_AS_REQ . . . . . . . . . . 12
- 6.2. Context Token Derived from KRB_AS_REP . . . . . . . . . . 15
- 6.3. Context Tokens Imported from RFC4121 . . . . . . . . . . . 16
- 7. Guidelines for Credentials Selection . . . . . . . . . . . . . 17
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
- 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
- 11. Normative References . . . . . . . . . . . . . . . . . . . . . 19
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
- Intellectual Property and Copyright Statements . . . . . . . . . . 23
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 2]
-
-Internet-Draft PKU2U November 2008
-
-
-1. Introduction
-
- The Generic Security Services Application Programming Interface (GSS-
- API) is a generic protocol and API for providing authentication and
- session protection to applications. It is generic in that it
- supports multiple authentication mechanisms. Today there exists only
- one workable, widely deployed, standards-track GSS-API mechanism: the
- Kerberos V GSS-API mechanism [RFC1964] [RFC4121], which is based on
- Kerberos V [RFC4120]. There is a need to provide a GSS-API mechanism
- which does not require Kerberos V Key Distribution Center (KDC)
- infrastructure, and which supports the use of public key
- cryptography, particularly Public Key Infrastructure (PKI) [RFC5280],
- including the use of public key certificates without a PKI.
-
- This document specifies such a mechanism: the Public Key User to User
- mechanism (PKU2U).
-
- PKU2U is based on building blocks taken from Kerberos V [RFC4120],
- PKINIT, [RFC4556] (which in turn uses PKI [RFC5280]) building
- blocks), and the Kerberos V GSS-API mechanism [RFC1964] [RFC4121].
- In spite of using Kerberos V building blocks, PKU2U does not require
- any Kerberos V KDC infrastructure. And though PKU2U also uses PKI
- building blocks, PKU2U can be used without a PKI by pre-sharing
- certificates and/or pre-associating name/certificate bindings.
-
- Therefore PKU2U can be used for true peer-to-peer authentication, as
- well as for PKI-based authentication.
-
-
-2. Conventions Used in This Document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- In this document, the GSS-API initiator or acceptor is referred to as
- the peer when the description is applicable to both the initiator and
- the acceptor.
-
-
-3. The PKU2U Realm Name
-
- The PKU2U realm name is defined as a reserved Kerberos realm name per
- [KRB-NAMING], and it has the value of "WELLKNOWN:PKU2U".
-
- The PKU2U realm name has no meaning, but is intended to be used in
- the Kebreros V Protocol Data Units (PDUs) that are re-used by PKU2U
- wherever realm names are needed. Unless otherwise specified, the
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 3]
-
-Internet-Draft PKU2U November 2008
-
-
- realm name in any Kerberos message used by PKU2U is the PKU2U realm
- name.
-
-
-4. The NULL Principal Name
-
- The NULL Kerberos principal name is defined as a well-known Kerberos
- principal name based on [KRB-NAMING]. The value of the name-type
- field is KRB_NT_WELLKNOWN [KRB-NAMING], and the value of the name-
- string field is a sequence of two KerberosString components:
- "WELLKNOWN", "NULL".
-
- The NULL Kerberos principal name is used in the Kerberos messages
- where there is no Kerberos representation of the principal name, for
- example, when the client name is a Distinguished Name. When the NULL
- principal name is used in the Kerberos messages, the principal name
- is either not used or provided separately (for example in the
- PA_PKU2U_NAME padata defined in Section 6.1).
-
-
-5. PKU2U Principal Naming
-
- The GSS-API targ_name supplied for the initiator MUST NOT be
- GSS_C_NO_NAME in PKU2U.
-
- PKU2U principal names can be Kerberos principal names, and they can
- also be distiguished names, or subject alternative names [RFC5280] as
- they appear in the certificate of any PKU2U peer, as well as any
- names agreed to out of band that do not appear in the peer
- certificates.
-
- Certificates may be associated with multiple principal names. This
- presents problems for the GSS-API bindings of a PKI-based mechanism
- because, for example, for any given, established GSS-API security
- mechanism there can be only one initiator name, and one acceptor
- name, and credential handles may be associated with only one name.
- We resolve these problems as follows:
-
- o We define multiple GSS-API name types corresponding to several
- GeneralName choices [RFC5280], along with syntaxes, display forms,
- and exported name token formats for each. For most of the name-
- types listed below the exported name token formats consists of a
- GeneralName with the usual exported name token header as per-
- RFC2743. Two name-types are shared with the Kerberos V mechanism
- and use the Kerberos V mechanism's query and display syntaxes,
- canonicalization rules, and exported name token format.
-
-
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 4]
-
-Internet-Draft PKU2U November 2008
-
-
- o The cred_name of a credential handle acquired with
- GSS_C_NT_NO_NAME as the desired_name SHOULD be the Distinguished
- Name (DN) of the certificate underlying the credential. If there
- are multiple certificates and private keys, then either one MUST
- be selected by local, implementation-specific means, or credential
- acquisition with GSS_C_NT_NO_NAME MUST fail (implementers may
- choose which of these two behaviors to provide).
-
- o When using desired_name values other than GSS_C_NT_NO_NAME for
- credential handle acquisition then the implementation MUST use
- exact matching of the given desired_name to a certificate's DN or
- Subject Alternative Names (SANs) for all name-types given below,
- except for GSS_C_NT_DN, where matching rules are fuzzier and given
- below. The names of a X.509 certificate will be compared to the
- given desired_name in this order: certificate DN first, then SANs
- in the order in which they appear in the certificate. When
- multiple certificates and private keys are available the order in
- which the various certificates are searched is significant; no
- canonical certificate collation order is defined herein.
-
- o The cred_name of a credential object acquired with a desired_name
- other than GSS_C_NT_NO_NAME MUST be equal to the certificate DN or
- SAN matched by the given desired_name.
-
- o We provide a method (see below) by which initiators can assert, in
- their context tokens, one of these names of the initiator. We
- also provide a method of asserting names that do not appear in a
- X.509 certificate, in which case the binding of X.509 certificate
- to the asserted name is done out-of band. The name to be
- asserted, of course, is the cred_name of the cred_handle passed to
- GSS_Init_sec_context().
-
- o The initiator's context tokens may also indicate what is the
- expected name of the acceptor -- the targ_name passed in to
- GSS_Init_sec_context().
-
- o No attempt is made to map Kerberos V realm names to trust anchor
- certificate authority (CA) names.
-
- o We provide a method of matching host-based service principal names
- to acceptor certificates, so that: a) initiators need not know the
- particulars of an acceptor's certificates' names a priori, b)
- acceptors can select a credential to accept a security context
- with that the initiator will accept, c) existing certificates for
- web servers, may be used as host-based service principal names as
- though the service name were "HTTP".
-
- Thus GSS-API initiator applications that use the GSS_C_NO_NAME as the
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 5]
-
-Internet-Draft PKU2U November 2008
-
-
- desired_name arguments of GSS_Acquire_cred() and GSS_Add_cred(), or
- GSS_C_NO_CREDENTIAL as the cred argument of GSS_Init_sec_context()
- will assert the selected X.509 certificate's subject DN, and that
- X.509 certificate's subject DN will be the name returned by
- GSS_Inquire_cred() and GSS_Inquire_cred_by_mech().
-
- And portable GSS-API initiator applications using
- GSS_C_NT_HOSTBASED_SERVICE for naming acceptors (i.e., for importing
- a name to use as the targ_name input argument of
- GSS_Init_sec_context()) will have a reasonable chance of success in
- authenticating peers with X.509 certificates predating this
- specification.
-
-5.1. GSS_C_NT_DN
-
- The name type GSS_C_NT_DN, with Object Identifier (OID) <TBD> (see
- Section 10), is defined. This corresponds to the 'directoryName'
- choice of the 'GeneralName' Abstract Syntax Notation One (ASN.1)
- [CCITT.X680.2002] type defined in [RFC5280].
-
- The query syntax and display form for names of this type SHALL be as
- described in [RFC4514].
-
- As RFC4514 says, "[c]omparison of DNs for equality is to be performed
- in accordance with the distinguishedNameMatch matching rule
- [RFC4517]".
-
- There is no reasonable way to canonicalize names of this type without
- providing certificates to match query forms of GSS_C_NT_DN against,
- such as in the form of a directory. Therefore
- GSS_Canonicalize_name() as applied to names imported with the
- GSS_C_NT_DN name-type MUST search available certificate databases, or
- directories, or MUST fail. No method of locating and searching
- directories for matching certificate DNs is specified herein. Note
- though that GSS_Inquire_cred_by_mech() and GSS_Inquire_sec_context()
- can and, indeed, MUST return "mechanism names" (MN) (see [RFC2743]).
-
- The exported name token format for names of this type SHALL be the
- Distinguished Encoding Rules (DER) [CCITT.X680.2002]
- [CCITT.X690.2002] encoding of a GeneralName with directoryName as the
- choice.
-
- Implementation support for this name type is REQUIRED.
-
-5.2. GSS_C_NT_HOSTNAME
-
- The name type GSS_C_NT_HOSTNAME, with OID <TBD>, is defined. This
- corresponds to the 'dNSName' choice of the 'GeneralName' ASN.1 type
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 6]
-
-Internet-Draft PKU2U November 2008
-
-
- defined in [RFC5280].
-
- The query syntax for names of this type SHALL be a DNS name [RFC1034]
- in either ACE or Unicode form [RFC3490].
-
- The display and canonical form of names of this type SHALL be a DNS
- domain name in ACE form, with character case folded down.
- Canonicalization consists merely of applying the ToASCII() function
- and case-folding the result.
-
- The exported name token format for names of this type SHALL be the
- DER encoding of a GeneralName with dNSName as the choice and the DNS
- domain name in ACE form and case folded down.
-
- Implementation support for this name type is OPTIONAL.
-
-5.3. GSS_C_NT_EMAIL_ADDR
-
- The name type GSS_C_NT_EMAIL_ADDR, with OID <TBD>, is defined. This
- corresponds to the 'rfc822Name' choice of the 'GeneralName' ASN.1
- type defined in [RFC5280].
-
- The query syntax and display form for names of this type SHALL be the
- text representation of an 'addr-spec' as defined in [RFC0822].
-
- The canonical form of names of this type SHALL be the query form with
- case folded down. Note that the domain name part of an addr-spec is
- a "domain name slot" and so the canonicalization rules for
- GSS_C_NT_HOSTNAME given above apply here as well.
-
- The exported name token form for this name type SHALL be the DER-
- encoding of a GeneralName with the rfc822Name choice.
-
- Implementation support for this name type is OPTIONAL.
-
-5.4. GSS_KRB5_NT_PRINCIPAL_NAME
-
- PKU2U supports the use of GSS_KRB5_NT_PRINCIPAL_NAME names [RFC1964].
-
- The query, display, canonical and exported name token forms of names
- of this type SHALL be as specified in RFC4121. The realm name part
- of GSS_KRB5_NT_PRINCIPAL_NAME names is optional for the query syntax;
- when canonicalized, names of this type lacking a realm name will have
- the well-known PKU2U realm name affixed.
-
- When the realm name of a GSS_KRB5_NT_PRINCIPAL_NAME NAME is defaulted
- or otherwise is the well-known PKU2U realm name, then the "cname"' or
- sname fields of the Kerberos V PDUs used to construct PKU2U security
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 7]
-
-Internet-Draft PKU2U November 2008
-
-
- context tokens MUST be set to the principal name part of the given
- NAME. Otherwise the PA_PKU2U_NAME pre-authentication data MUST be
- used to indicate a name of id-pkinit-san type [RFC4556] corresponding
- to the given NAME. See Section 5.4.
-
- No attempt is made to map Kerberos V realm names to trust anchor
- certificate authority (CA) names.
-
- Note that having more than one mechanism share name-types has
- implications for multi-mechanism, pluggable GSS-API implementations
- (commonly referred to as "mechglue"). Specifically:
-
- o It must be the responsibility of the mechanism, not of the
- mechglue, to ensure that the standard exported name token header
- (which includes a mechanism OID), is included in exported name
- tokens. The exported name token for a GSS_KRB5_NT_PRINCIPAL_NAME
- MN produced by PKU2U would have PKU2U's mechanism OID in the
- header.
-
- o A pluggable mechglue must be able to find a mechanism that can
- import an exported name token if an available mechanism can
- produce that exported name token. For example, a pluggable
- mechglue where PKU2U is available but where the Kerberos V
- mechanism [RFC1964] is not should still be able to import exported
- Kerberos V name tokens since PKU2U can create such tokens. One
- way to do this would be for the mechglue to try the mechanism
- named in the exported name token header, if it is available, else
- try all other available mechanisms until one succeeds or all fail.
- It would be reasonable for a mechglue implementer to require that
- the Kerberos V mechanism be available if PKU2U is too.
-
- o It must be possible for GSS_Acquire_cred(), GSS_Add_cred() to use
- a Kerberos V "mechanism name" (MN; see [RFC2743]) as desired_name
- argument value to acquire a PKU2U credential. Similarly, it must
- be possible to use a Kerberos V MN as the target_name in a call to
- GSS_Init_sec_context with PKU2U as the mech OID. A multi-
- mechanism mechglue implementer would likely have a mechglue-layer
- NAME object that internally keeps a reference to a NAME object
- produced by the underlying mechanism, but a pluggable mechglue
- could not expect two different mechanisms to be able to share
- their internal NAME objects. A clever implementer can work around
- this by exporting the one mechanism's MN and then re-importing
- using the target mechanism's GSS_Import_name() service function.
-
- o It must be possible for the credential inquiry functions (e.g.,
- GSS_Inquire_cred() and GSS_Inquire_cred_by_mech()) to return a
- cred_name that is an MN of a different mechanism than the
- credential element being inquired.
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 8]
-
-Internet-Draft PKU2U November 2008
-
-
- Implementation support for this name type, with defaulted realm name
- or with the PKU2U realm name is REQUIRED, but it is OPTIONAL for use
- with any other realm names.
-
-5.5. GSS_C_NT_ANONYMOUS
-
- This is a generic GSS-API name-type. Implementation support for this
- name type is OPTIONAL. See Section 6.1 for more information.
-
- See [RFC2743] and [RFC2744] for more information about this name
- type.
-
- The PKU2U mechanism only supports anonymous initiators, not
- acceptors.
-
- Implementation support for this name type is RECOMMENDED.
-
-5.6. GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based Principal Names
- to Acceptor Certificates
-
- Support for GSS_C_NT_HOSTBASED_SERVICE names is REQUIRED as described
- herein.
-
- The query form of this name type is as per-RFC2743. The canonical
- and exported name token forms are as per-RFC1964. The display form
- of this name type is left unspecified, but should either be as per-
- RFC2743 or the same as the display form for
- GSS_KRB5_NT_PRINCIPAL_NAME [RFC1964].
-
- Initiators using names of type GSS_C_NT_HOSTBASED_SERVICE to identify
- target acceptors represent these names as Kerberos V principal names
- as per [RFC1964] but with a well-known realm name of "WELLKNOWN:
- PKU2U" (see Section 5.4).
-
- Acceptors match such names to acceptor certificates as follows.
- Initiators then match the certificate chosen by the acceptor in the
- same manner.
-
- Initiators can also assert host-based service names as the initiator
- name. In this case acceptors MUST also apply the matching rules
- below, in order, to validate the initiator's assertion.
-
- 1. If there is an out-of-band binding of the peer's host-based
- service name to its certificate, then the certificate matches.
-
- 2. If the peer has a certificate with an id-pkinit-san subject
- alternative name matching the initiator-provided acceptor name,
- then the X.509 certificate matches.
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 9]
-
-Internet-Draft PKU2U November 2008
-
-
- 3. If a X.509 certificate has a dNSName SAN that matches the
- hostname part of the host-based service principal name, and
- either the anyExtendedKeyUsage extended key usage (EKU), or no
- EKU is present, or an EKU is present which corresponds to the
- service part of the host-based service principal name, then the
- X.509 certificate matches. The id-kp-serverAuth EKU SHALL be
- considered to match the 'HTTP' service name. (See Section 10,
- IANA considerations, where the GSS-API service name registry is
- extended to include an EKU for each service name.)
-
- 4. Implementations SHOULD, subject to local configuration, allow
- matches where the single-component cn of the DN of a X.509
- certificate matches the hostname part of the host-based service
- name, for some or all service names. This feature is needed to
- allow the use of existing X.509 web certificates.
-
- Implementation support for this name type as an acceptor name is
- REQUIRED. Implementation support for this name type as an initiator
- name is OPTIONAL.
-
-
-6. The Protocol Description and the Context Establishment Tokens
-
- The PKU2U mechanism is a GSS-API mechanism based on [RFC4120],
- [RFC4556] and [RFC4121].
-
- The per-message tokens of the PKU2U mechanism are the same as those
- of the Kerberos V GSS-API mechanism [RFC4121].
-
- The GSS_Pseudo_random() function [RFC4401] of the PKU2U is the same
- as that of the Kerberos V GSS-API mechanism [RFC4402].
-
- The PKU2U security context token exchange consists of KRB_AS_REQ and
- KRB_AS_REP (and KRB_ERROR) Kerberos KDC PDUs (with no changes to
- their ASN.1 description, but with other minor changes/requirements
- described below) as context tokens, with the acceptor as the KDC,
- followed by context tokens from [RFC4121] using the Kerberos V Ticket
- PDU issued by the acceptor-as-KDC. PKINIT [RFC4556] is the only
- acceptable pre-authentication method in this document. Caching the
- ticket issued by the acceptor allows subsequent security context
- exchanges between the same to peers to use a single context token
- round-trip -- a "fast reconnect" feature.
-
- PKU2U differs from Kerberos V with PKINIT in several minor ways as
- follows (this is not a complete list):
-
-
-
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 10]
-
-Internet-Draft PKU2U November 2008
-
-
- o KDC PDUs are not exchanged as usual in Kerberos, but wrapped as
- [the first two] GSS-API context tokens.
-
- o PKU2U does not use KDC certificates.
-
- o PKU2U adds pa-data types for carrying the initiator's assertion of
- its name and the targ_name passed to GSS_Init_sec_context().
-
- PKU2U differs from the Kerberos V GSS-API mechanism in several ways:
-
- o KDC PDUs are not exchanged as described in [RFC4120], but wrapped
- as GSS-API context tokens.
-
- o PKU2U allows the use of principal names matching PKI naming (see
- Section 5). PKU2U does support the use of Kerberos V naming, but
- requires only support of Kerberos V naming to a limited extent
- (full support is optional).
-
- o PKU2U adds an extension [GSS-EXTS] to the RFC4121 initial context
- token for binding the AP-REQ to the AS exchange that precedes is
- (that is, when the initiator has to request a ticket from the
- acceptor).
-
- o The number of round-trips can vary. If the initiator already has
- a ticket for the acceptor then the context token exchange will be
- half a round-trip or one round-trip, as per RFC4121. Otherwise
- one or two round-trips are added for the AS exchanges needed to
- acquire a ticket. Note that two AS exchanges may be required when
- the initiator's initial choice of X.509 certificate does not match
- the acceptor's trust anchors, in which case the acceptor SHOULD
- reply with a KRB-ERROR with TD-TRUSTED-CERTIFIERS indicating what
- the acceptor's trust anchors are, and then the initiator can
- engage in a second AS exchange within the same GSS-API context.
-
- To recapitulate, the acceptor and the initiator communicate by
- tunneling the authentication service exchange messages through the
- use of the GSS-API tokens and application traffic. In the event of
- security context token loss, message duplication, or out of order
- message delivery, the security context MUST fail to establish.
-
- All security context establishment tokens MUST follow the
- InitialContextToken syntax defined in Section 3.1 of [RFC2743].
- PKU2U is identified by the Objection Identifier (OID) id-kerberos-
- pku2u.
-
-
-
-
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 11]
-
-Internet-Draft PKU2U November 2008
-
-
- The PKU2U OID is:
-
- id-kerberos-pku2u ::=
- { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
- pku2u(7) }
-
- All context establishment tokens consist of some Kerberos V PDU or
- another, prefixed with a two-octet token type ID, and the
- InitialContextToken header (see above).
-
- The innerToken described in section 3.1 of [RFC2743] and subsequent
- GSS-API mechanism tokens have the following formats: it starts with a
- two-octet token-identifier (TOK_ID), followed by a Kerberos message.
- The TOK_ID values for the AS-REQ message and the AS-REP message are
- defined in the table blow:
-
- Token TOK_ID Value in Hex
- -----------------------------------------------
- KRB_AS_REQ 05 00
- KRB_AS_REP 06 00
-
- The TOK_ID values for all other Kerberos messages are the same as
- defined in [RFC4121].
-
- It should be noted that by using anonymous PKINIT [KRB-ANON], PKU2U
- can authenticate the acceptor without revealing the initiator's
- identity
-
-6.1. Context Token Derived from KRB_AS_REQ
-
- When the initiator does not have a service ticket to the acceptor, it
- requests a ticket from the acceptor instead of from the KDC by
- constructing a KRB_AS_REQ PDU [RFC4120] and using it as the context
- token, with a token type ID prefixed. This will be the initiator's
- initial context token, therefore it MUST also have the standard
- header bearing the OID of the mechanism being used (in this case,
- PKU2U's OID).
-
- The initiator MUST NOT set any KDC options in the 'kdc-options' field
- of the AS-REQ.
-
- The 'realm' field of the AS-REQ MUST be set to the PKU2U well-known
- PKU2U realm name ("WELLKNOWN:PKU2U" [KRB-NAMING].
-
- If the initiator wishes to assert a name of type
- GSS_KRB5_NT_PRINCIPAL_NAME or GSS_C_NT_HOSTBASED_SERVICE, then it
- MUST set the 'cname' field of the AS-REQ accordingly if and only if
- the realm name part of the given name object is defaulted or the
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 12]
-
-Internet-Draft PKU2U November 2008
-
-
- well-known PKU2U realm name. Otherwise the initiator MUST add a pa-
- data element (see below) stating the name that the initiator wishes
- to assert, it MUST set the cname field to the NULL principal name as
- defined in Section 4.
-
- If the targ_name passed to GSS_Init_sec_context() is of type
- GSS_C_NT_HOSTBASED_NAME then the initiator sets the 'sname' field of
- the AS-REQ to match the parsed name as per [RFC4121]. If the target
- name does not have a representation as a Kerberos principal name per
- [RFC1964], then the initiator MUST add a pa-data element (see below)
- stating the given targ_name and the initiator MUST set the 'sname'
- field of the AS-REQ to the NULL principal name as defined in
- Section 4.
-
- The padata used to convey initiator and target names is of type
- PA_PKU2U_NAME <136> and it's value consists of the DER
- [CCITT.X680.2002] [CCITT.X690.2002] encoding of the ASN.1 type
- InitiatorNameAssertion (with explicit tagging).
-
- InitiatorName ::= CHOICE {
- -- -1 -> certificate DN
- -- 0..16384 -> subjectAltName named by
- -- this index
- sanIndex INTEGER (-1..16384), -- DN or SAN
- nameNotInCert GeneralName, -- name not present in cert
- -- (see RFC5280 for definition
- of GeneralName)
- ...
- }
-
- TargetName ::= CHOICE {
- exportedTargName OTCET STRING, -- exported krb5 name
- generalName [0] GeneralName, -- all other PKI names
- -- (tagged to distinguish
- -- from nameNotInCert
- -- choice of InitiatorName)
- ...
- }
-
- InitiatorNameAssertion ::= SEQUENCE {
- initiatorName InitiatorName OPTIONAL,
- targetName TargetName OPTIONAL,
- ...
- }
-
- The initiatorName, if present, contains the initiator's name. The
- initiator can fill out either the sanIndex field or the nameNotInCert
- field to indicate the name of the initiator.
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 13]
-
-Internet-Draft PKU2U November 2008
-
-
- The sanIndex field, if present, is used to refer to either the
- Distinguished Name or the SubjectAltName in the initiator's X.509
- certificate. A sanIndex value of -1 value refers to the initiator's
- certificate's DN. All other legal values of sanIndex refer to the
- corresponding element of the SubjectAltName sequence. A value of 0
- means the first instance of GeneralName in the SubjectAltName
- sequence, and 1 means the second, and so on. If the sanIndex value
- is equal or biger than the number of GeneralName elements in the
- SubjectAltName, the security context establishment attempt MUST fail.
-
- The nameNotInCert field, if present, contains the initiator's
- GeneralName.
-
- If an initiator name assertion is included, the acceptor MUST verify
- that this asserted name is either present in the initiator's
- certificate or otherwise bound to the initiator's certificate by out-
- of-band provisioning (e.g., by a table lookup). Failure to validate
- the asserted initiator's name MUST cause GSS_Accept_sec_context() to
- return an error and, optionally, to output a KRB_ERROR context token
- as per-RFC4121.
-
- The initiatorName field MUST NOT be present if the initiator is
- anonymous or if the 'cname' field of the AS-REQ is not the NULL name
- (see Section 4).
-
- Target names passed to GSS_Init_sec_context() that can be represented
- as Kerberos V principal names, namely, names of
- GSS_KRB5_NT_PRINCIPAL_NAME and GSS_C_NT_HOSTBASED_SERVICE, MUST be
- represented as the 'sname' field of the AS-REQ or as the
- exportedTargName choice of TargetName (if the realm part is not the
- PKU2U realm name). The contents of the exportedTargName octet string
- MUST be an exported name token for the Kerberos V mechanism
- containing a Kerberos V principal name.
-
- Other target names are represented as a generalName choice of
- TargetName. These may be present in an acceptor certificate, or
- agreed out of band.
-
- The acceptor MUST select an appropriate acceptor credential that
- matches the AS-REQ's 'sname' (if not NULL) or the targetName provided
- in the InitiatorNameAssertion, when present.
-
- The targetName field MUST NOT be present if the 'sname' field of the
- AS-REQ is not the NULL name. The targetName field MUST be present if
- the 'sname' field of the AS-REQ is the NULL name.
-
- The PA_PKU2U_NAME padata SHOULD NOT be present when the initiatorName
- and targetName both shouldn't be present.
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 14]
-
-Internet-Draft PKU2U November 2008
-
-
- Implementation note: the encrypted part of a PKU2U Ticket can be
- anything at all since the only entity that will consumer a given
- PKU2U Ticket is the same entity that issued it. Implementers may
- choose to use the traditional EncTicketPart ASN.1 type [RFC4120] and
- DER encoding.
-
-6.2. Context Token Derived from KRB_AS_REP
-
- When the initiator's initial context token is a AS-REQ then the
- acceptor MUST reply with either a KRB-ERROR token as per [RFC4121] or
- a token derived from a KRB_AS_REP PDU [RFC4120] constructed to
- respond to the initiator's KRB_AS_REQ.
-
- The initiator MUST use PKINIT pre-authentication and the acceptor
- MUST require it. If the initiator does not use PKINIT pre-
- authentication then the acceptor MUST respond with a KRB-ERROR and
- indicate that PKINIT is required.
-
- If the initiator's KRB_AS_REQ token is valid, and the asserted
- initiator's name, if present, is bound with the initiator's
- certificate, and the acceptor can select a certificate based on the
- initiator's asserted targ_name, the acceptor then constructs a
- KRB_AS_REP using PKINIT as described in [RFC4556], except that the
- acceptor's certificate is used in the place of the KDC certificate.
- If and only if the initiator's X.509 certficate is validated using
- PKI, the acceptor SHOULD include an authorization element
- AD_INITIAL_VERIFIED_CAS [RFC4556] in the returned ticket. If an
- InitiatorName is included in the PA_PKU2U_NAME padata in the request,
- an authorization element of the type ad-pku2u-client-name <143> MUST
- be included in the returned ticet and this authorization element
- contains the DER encoded InitiatorName in the request.
-
- The initiator then validates the KRB-AS-REP reply context token
- according to Section 3.1.5 of [RFC4120] and Section 3.2.4 of
- [RFC4556]. The inclusion of the EKU KeyPurposeId [RFC5280] id-
- pkinit-KPKdc in the X.509 certificate in the response is not
- applicable when PKU2U is used because there is no KDC involved in
- this protocol. The initiator MUST verify that the acceptor's
- certificate is bound with the targ_name passed in to
- GSS_Init_sec_context(), by verifying either the targ_name matches
- with either the subject DN or one instance of the SubjectAltName name
- in the acceptor's certificate, or otherwise the targ_name is bound
- with the acceptor's certificate by out-of-band provisioning (e.g., by
- a table lookup). Failure to validate this name binding MUST cause
- the authentication to be rejected.
-
- The 'flags' field of the AS-REP MUST have only the 'initial' and
- 'pre-authent' flags set.
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 15]
-
-Internet-Draft PKU2U November 2008
-
-
- The 'authtime' field of the AS-REP MUST be set to the acceptor's
- current time as it is when it formats the AS-REP.
-
- Otherwise all other aspects of the AS-REP are as described in
- [RFC4120].
-
- The values of the tkt-vno, realm and 'sname' fields of the Ticket
- issued by the acceptor are unspecified. The initiator MUST NOT
- examine them for correctness. Cut-n-paste attacks are prevented by
- the fact that PKU2U provides integrity protection for all cleartext
- in Kerberos V PDUs used by PKU2U (and for the mechanism OID).
-
-6.3. Context Tokens Imported from RFC4121
-
- Once the initiator has a Kerberos V Ticket for the acceptor the
- security context token exchange will continue with those of the
- Kerberos V GSS-API mechanism [RFC4121] with the following
- modifications:
-
- o The mechanism OID of PKU2U SHALL be used instead of that of the
- Kerberos V GSS-API mechanism;
-
- o The 'crealm' field of the initiator's Authenticator MUST be set to
- the PKU2U realm name and if the 'cname" field is the NULL
- principal name, an authorization element of the type ad-pku2u-
- client-name <143> MUST be included in the authenticator and this
- authorization element contains the DER encoded InitiatorName in
- the AS-REQ based on which the ticket was obtained;
-
- o The sub-session key MUST be used in the initiator's Authenticator;
-
- o The contents of the encrypted part of the Ticket can be
- implementation specific since the only entity consuming it will be
- the same entity that issues it;
-
- o If the initiator's initial context token is a KRB_AS_REQ token
- (i.e., not KRB_AP_REQ token), then the Exts field in the
- Authenticator of the KRB_AP_REQ-derived token MUST contain an
- extension [GSS-EXTS] of the type GSS_EXTS_FINISHED <2> as defined
- next in this section.
-
- The 'cusec', 'ctime', 'seq-number' and 'authorization-data' fields of
- the Authenticator are set as per [RFC4121] and [RFC4120].
-
- The 'cksum' field of the Authenticator MUST be set as per [RFC4121].
- The extension data of the GSS_EXTS_FINISHED extension type [GSS-EXTS]
- contains the DER encoding of the ASN.1 structure KRB-FINISHED.
-
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 16]
-
-Internet-Draft PKU2U November 2008
-
-
- GSS_EXTS_FINISHED 2
- --- The type for the checksum extension.
-
- KRB-FINISHED ::= SEQUENCE {
- gss-mic [1] Checksum,
- -- Contains the checksum (RFC3961) of the GSS-API tokens
- -- that have been exchanged between the initiator and the
- -- acceptor and prior to the containing AP-REQ GSS-API token.
- -- The checksum is performed over the GSS-API
- -- context tokens in the order that the tokens were sent.
- ...
- }
-
- The gss-mic field contains a Kerberos checksum [RFC3961] that is
- computed over all the preceding context tokens of this GSS-API
- context (including the InitialContextToken header), concatenated in
- chronological order (note that GSS-API context token exchanges are
- synchronous). The checksum type is the required checksum type of the
- enctype of the subkey in the authenticator, the protocol key for the
- checksum operation is the authenticator subkey, and the key usage
- number is KEY_USAGE_FINISHED <41>.
-
- The acceptor MUST process the KRB_AP_REQ token as usual for RFC4121,
- except that if the context token exchange included an AS exchange,
- then the acceptor MUST also validate the GSS_EXTS_FINISHED and return
- an error if it is not valid or not present. But if a KRB_AP_REQ
- context token is the initial context token then the acceptor MUST
- return an error if GSS_EXTS_FINISHED is present.
-
- The GSS_EXTS_FINISHED (along with the ticket) binds the second part
- of the context token exchange to the first, and it binds the pa-data
- used in the request as well (this needs to be done because PKINIT
- does not bind pa-data other than PKINIT pa-data from the request).
- GSS_EXTS_FINISHED also protects all otherwise unauthenticated
- plaintext in Kerberos V PDUs. Note that GSS_EXTS_FINISHED also
- protects the mechanism OID in the InitialContextToken header.
-
- The acceptor MUST verify that the ad-pku2u-client-name authorization
- element is present in the authenticator if and only there is an
- authorization element of the same type in the ticket and the values
- of these two elements MUST match exactly based on bit-wise
- comparison.
-
-
-7. Guidelines for Credentials Selection
-
- If a peer, either the initiator or the acceptor, has multiple pairs
- of public-key private keys and certificates, a choice is to be made
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 17]
-
-Internet-Draft PKU2U November 2008
-
-
- in choosing the best fit. The trustedCertifiers field in the PA-PK-
- AS-REQ structure [RFC4556] SHOULD be filled by the initiator, to
- provide hints for guiding the selection of an appropriate certificate
- chain by the acceptor.
-
- If the initiator's X.509 certificate cannot be validated according to
- [RFC5280], the acceptor SHOULD send back the TD-TRUSTED-CERTIFIERS
- structure [RFC4556] that provides hints for guiding the selection of
- an appropriate certificate by the initiator. In this case
- GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED, and the
- initiator gets to try again in its subsequent AS-REQ token.
-
- The GSS-API does not provide a programming interface to make this
- credential selection interactive, though implementers may provide
- methods for user interaction related to credential selection and
- acquisition (e.g., name and password/PIN prompts). Whenever the
- execution context allows for direct interaction of the mechanism with
- the user then it is RECOMMENDED that implementations interact with
- the user to select a credential whenever multiple credentials are
- equally usable and no other mechanism is available to inform the
- credential selection.
-
- If the certificates cannot be selected interactively, multiple
- certificates are equally usable, and there is no other mechanism
- available for credential selection, then it is RECOMMENDED that
- initiators fail the context. Users should be able to retry using a
- specific credential (this requires that distinct credentials have
- distinct names that can be used to acquire each credential
- separately).
-
-
-8. Security Considerations
-
- The security considerations in [RFC4120], [RFC4121], [RFC4556] and
- [RFC5280] apply here. This mechanism relaxes some requirements of
- PKINIT and adds a device for protecting otherwise unauthenticated
- plaintext in the protocol (see Section 6.3) -- it is crucial that
- this device be faithfully implemented. It is also crucial that both
- the initiator and the acceptor MUST be able to verify the binding
- between the signing key and the asserted identity.
-
- Note that PKU2U is just as susceptible to replays of AP-REQs as the
- traditional Kerberos V GSS-API mechanism [RFC4121], though only when
- using an AP-REQ as the initial security context token. It is
- important, therefore, to use a replay cache to detect replays.
-
-
-
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 18]
-
-Internet-Draft PKU2U November 2008
-
-
-9. Acknowledgements
-
- The authors would like to thank Jeffrey Hutzelman for his insightful
- comments on the earlier revisions of this document.
-
- In addition, the following individuals have provided review comments
- for this document: Sam Hartman, Leif Johansson, Olga Kornievskaia,
- Martin Rex, and Sunil Gottumukkala.
-
- Ari Medvinsky provided help in editing the initial revisions of this
- document.
-
- The text for the DN mapping is compiled from the email discussions
- among the following individuals: Howard Chu, Martin Rex, Jeffrey
- Hutzelman, Kevin Coffman, Henry B. Hotz, Leif Johansson, and Olga
- Kornievskaia. Howard and Jeffery clearly illustrated the challenges
- in creating a unique mapping, while Nicolas and Martin demonstrated
- the relevance and interactions to GSS-API and Kerberos.
-
-
-10. IANA Considerations
-
- This document defines the PKU2U realm and the place-holder well-known
- principal name. The IANA registry for the reserved names should be
- updated to reference this document. Two entries are added: one entry
- for the well-known realm "WELLKNOWN:PKU2U", and another for the well-
- known principal name "WELLKNOWN/NULL".
-
- This document defines GSS_EXTS_FINISHED extension type. The
- corresponding IANA registry [GSS-EXTS] need to be updated to
- reference this document. The following single registration should be
- added in the registry for "Kerberos V GSS-API mechanism extension
- types": 2, "GSS-API token checksum", "Extension to provide a checksum
- for GSS-API tokens", the RFC # of this document.
-
- This document also instructs the IANA to extend the "SMI Security for
- Name System Designators Codes (nametypes)" registry to include an OID
- for each registration, and to allocate OIDs for the following GSS-API
- name-types in that registry:
- o gss-distinguished-name (GSS_C_NT_DN)
- o gss-hostname (GSS_C_NT_HOSTNAME)
- o gss-IP-address (GSS_C_NT_IP_ADDR)
- o gss-e-mail-address (GSS_C_NT_EMAIL_ADDR)
-
-
-11. Normative References
-
- [CCITT.X680.2002]
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 19]
-
-Internet-Draft PKU2U November 2008
-
-
- International International Telephone and Telegraph
- Consultative Committee, "Abstract Syntax Notation One
- (ASN.1): Specification of basic notation",
- CCITT Recommendation X.680, July 2002.
-
- [CCITT.X690.2002]
- International International Telephone and Telegraph
- Consultative Committee, "ASN.1 encoding rules:
- Specification of basic encoding Rules (BER), Canonical
- encoding rules (CER) and Distinguished encoding rules
- (DER)", CCITT Recommendation X.690, July 2002.
-
- [GSS-EXTS]
- Emery, S., "Kerberos Version 5 GSS-API Channel Binding
- Hash Agility", draft-ietf-krb-wg-gss-cb-hash-agility (work
- in progress), 2007.
-
- [KRB-ANON]
- Zhu, L. and P. Leach, "Kerberos Anonymity Support",
- draft-ietf-krb-wg-anon (work in progress), 2007.
-
- [KRB-NAMING]
- Zhu, L., "Additional Kerberos Naming Constraints",
- draft-ietf-krb-wg-naming (work in progress), 2007.
-
- [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
- text messages", STD 11, RFC 822, August 1982.
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
- RFC 1964, June 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2743] Linn, J., "Generic Security Service Application Program
- Interface Version 2, Update 1", RFC 2743, January 2000.
-
- [RFC2744] Wray, J., "Generic Security Service API Version 2 :
- C-bindings", RFC 2744, January 2000.
-
- [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
- "Internationalizing Domain Names in Applications (IDNA)",
- RFC 3490, March 2003.
-
- [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 20]
-
-Internet-Draft PKU2U November 2008
-
-
- Kerberos 5", RFC 3961, February 2005.
-
- [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
- Kerberos Network Authentication Service (V5)", RFC 4120,
- July 2005.
-
- [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
- Version 5 Generic Security Service Application Program
- Interface (GSS-API) Mechanism: Version 2", RFC 4121,
- July 2005.
-
- [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API
- Extension for the Generic Security Service Application
- Program Interface (GSS-API)", RFC 4401, February 2006.
-
- [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the
- Kerberos V Generic Security Service Application Program
- Interface (GSS-API) Mechanism", RFC 4402, February 2006.
-
- [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP): String Representation of Distinguished Names",
- RFC 4514, June 2006.
-
- [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP):
- Syntaxes and Matching Rules", RFC 4517, June 2006.
-
- [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial
- Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
- [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
- Housley, R., and W. Polk, "Internet X.509 Public Key
- Infrastructure Certificate and Certificate Revocation List
- (CRL) Profile", RFC 5280, May 2008.
-
-
-Authors' Addresses
-
- Larry Zhu
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
- US
-
- Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 21]
-
-Internet-Draft PKU2U November 2008
-
-
- Jeffery Altman
- Secure Endpoints
- 255 W 94th St
- New York, NY 10025
- US
-
- Email: jaltman@secure-endpoints.com
-
-
- Nicolas Williams
- Sun Microsystems
- 5300 Riata Trace Ct
- Austin, TX 78727
- US
-
- Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 22]
-
-Internet-Draft PKU2U November 2008
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2008).
-
- 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, THE IETF TRUST 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.
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al. Expires May 7, 2009 [Page 23]
-
-
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-07 18:23:37 +0000