`Request for Comments: 2535
`Obsoletes: 2065
`Updates: 2181, 1035, 1034
`Category: Standards Track
`
`
`Domain Name System Security Extensions
`
`Sta:us of this Memo
`
`
`D. Eastlake
`IBM
`March 1999
`
`
`
`This document specifies an Internet standards track protocol for the
`Internet community, and requests discussion and suggestions for
`improvements.
`Please refer to :he 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 (1999). All Rights Reserved.
`
`Abstract
`
`
`Extensions to the Domain Name System (DNS) are described that provide
`data integrity and authentication to security aware resolvers and
`applications through the use of cryptographic digital signatures.
`These digital signatures are included in secured zones as resource
`records. Security can also be provided through non—security aware
`DNS servers in some cases.
`
`
`
`The extensions provide for the storage of authenticated public keys
`in the DNS. This storage of keys can support general public key
`distribution services as well as DNS security.
`The stored keys
`enable security aware resolvers to learn the authenticating key of
`zones in addition to those for which they are initially configured.
`Keys associated with DNS names can be retrieved to support other
`protocols. Provision is made for a variety of key types and
`algorithms.
`
`the security extensions provide for the optional
`In addition,
`authentication of DNS protocol transactions and requests.
`
`This document incorporates feedback on RFC 2065 from early
`implementers and potential users.
`
`
`
`
`Eastlake
`
`Standards Track
`
`[Page 1]
`
`Petitioner Apple Inc. - Exhibit 1082, p. 1
`fi le:///C :/Users/j g01‘d007/AppData/Local/Temp/Low/D3TZ87LX.htm
`10/23/2014
`
`Apple V. VirnetX, et a1., IPR2014-00237 and IPR2014-00238
`
`Apple v. VirnetX, et al., IPR2014-00237 and IPR2014-00238
`Petitioner Apple Inc. - Exhibit 1082, p. 1
`
`
`
`RFC 2535
`
`
`DNS Security Extensions
`
`March 1999
`
`Acknowledgments
`
`The significant contributions and suggestions of the following
`persons (in alphabetic order)
`to DNS security are gratefully
`acknowledged:
`
`James M. Galvin
`John Gilmore
`Olafur Gudmundsson
`Charlie Kaufman
`
`Edward Lewis
`Thomas Narten
`Radia J. Perlman
`
`Jeffrey I. Schiller
`Steven (Xunhua) Wang
`Brian Wellington
`
`Table of Contents
`
`Abstract ................................................... 1
`Acknowledgments ........................ . ................... 2
`1. Overview of Contents .................................... 4
`
`2. Overview of the DNS Extensions .......................... 5
`2.1 Services Not Provided .................................. 5
`2.2 Key Distribution ....................................... 5
`2.3 Data Origin Authentication and Integrity ............... 6
`2.3.1 The SIG Resource Record .............................. 7
`2.3.2 Authenticating Name and Type Non—existence ........... 7
`2.3.3 Special Considerations With Time—to—Live ............. 7
`2.3.4 Special Considerations at Delega:ion Points .......... 8
`2.3.5 Special Considerations with CNAME .................... 8
`2.3.6 Signers Other Than The Zone .......................... 9
`2.4 D S Transaction and Request Authen:ication ............. 9
`
`3. The KEY Resource Record .................................. O
`3.1 KEY RDATA format ........................................ 0
`3.1.1 Objec: Types, DNS Names, and Keys ..................... 1
`
`3.1.2 The KEY RR Flag Field .................................1
`3.1.3 The Protocol Octet .................................. L3
`3.2 The KEY Algorithm Number Specification .................. 4
`3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15
`3.4 Determination of Zone Secure/Unsecured Status ......... 15
`
`3.5 KEY RRs
`in the Construction of Responses ................7
`4. The SIG Resource Record ..................................7
`4.1 SIG RDATA Format......................................L7
`4.1.1 Type Covered Field .................................. 18
`4.1.2 Algorithm Number Field ................................8
`4.1.3 Labels Field ..........................................8
`4.1.4 Original TTL Field ....................................9
`
`
`
`
`
`
`
`
`
`
`Eastlake
`
`RFC 2535
`
`Standards Track
`
`
`DNS Security Extensions
`
`[Page 2]
`
`March 1999
`
`
`4.1.5 Signature Expiration and Inception Fields ........... 19
`
`Petitioner Apple Inc.- Exhibit 1082, p. 2
`file:///C:/Users/jg01‘.d007/AppData/Local/Temp/Low/D3TZ87LXhtm
`10/23/2014
`
`Apple V. VirnetX, et al., lPR2014-00237 and IPR2014-00238
`
`Apple v. VirnetX, et al., IPR2014-00237 and IPR2014-00238
`Petitioner Apple Inc. - Exhibit 1082, p. 2
`
`
`
`
`
`4.1.6 Key Tag Field ....................................... 20
`4.1.7 Signer's Name Field ................................. 20
`4.1.8 Signature Field ..................................... 20
`4.1.8 1 Calculating Transaction and Request SIGs .......... 21
`4.2 SIG RRs
`in the Construction of Responses .............. 21
`4.3 Processing Responses and SIG RRs ...................... 22
`
`4.4 Signature Lifetime, Expiration, TTLs, and Validity....23
`5 Non—existent Names and Types ........................... 24
`5.1 The NXT Resource Record ............................... 24
`5.2
`XT RDATA Format ...................................... 25
`5 3 Additional Complexity Due to Wildcards ................ 26
`5.4 Example ............................................... 26
`5.5 Special Considerations at Delegation Points ........... 27
`5.6 Zone Transfers ........................................ 27
`5.6.1 Full Zone Transfers ................................. 28
`5.6.2 Incremental Zone Transfers .......................... 28
`6. How to Resolve Securely and the AD and CD Bits ......... 29
`6.1 The AD and CD Header Bits ............................. 29
`6.2 Staticly Configured Keys .............................. 31
`6.3 Chaining Through The DNS .............................. 31
`
`6.3.1 Chaining Through KEYs ............................... 31
`6.3.2 Conflicting Data .................................... 33
`6.4 Secure Time ........................................... 33
`7. ASCII Representation of Security RRs ................... 34
`
`7.1 Presentation of KEY RRs ............................... 34
`7.2 Presentation of SIG RRs ............................... 35
`7.3 Presentation of NXT RRs ............................... 36
`8 Canonical Form and Order of Resource Records ........... 36
`8.1 Canonical RR Form ..................................... 36
`8.2 Canonical DNS Name Order .............................. 37
`8.3 Canonical RR Ordering Within An RRset ................. 37
`8.4 Canonical Ordering of RR Types ........................ 37
`9 Conformance ............................................ 37
`9.1 Server Conformance .................................... 37
`9.2 Resolver Conformance .................................. 38
`10. Security Considerations ............................... 38
`11.
`IANA Considerations ................................... 39
`References ................................................ 39
`Author's Address .......................................... 41
`
`Appendix A: Base 64 Encoding .............................. 42
`Appendix B: Changes from RFC 2065 ......................... 44
`Appendix C: Key Tag Calculation ........................... 46
`Full Copyright Statement .................................. 47
`
`Eastlake
`
`RFC 2535
`
`
`
`Standards Track
`
`
`DNS Security Extensions
`
`[Page 3]
`
`March 1999
`
`1. Overview of Contents
`
`This document standardizes extensions of the Domain Name System (DNS)
`protocol
`to support DNS security and public key distribution. It
`assumes that the reader is familiar with the Domain Name System,
`
`Petitioner Apple Inc. - Exhibit 1082, p. 3
`file:///C :/Users/j gordo07/AppData/Local/Temp/Low/D3TZ87LX.htm
`10/23/2014
`
`Apple V. VirnetX, et a1., IPR2014—00237 and IPR2014—00238
`
`Apple v. VirnetX, et al., IPR2014-00237 and IPR2014-00238
`Petitioner Apple Inc. - Exhibit 1082, p. 3
`
`
`
`particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An
`earlier version of these extensions appears in RFC 2065. This
`replacement for that RFC incorporates early implementation experience
`and requests from potential users.
`
`Sec:ion 2 provides an overview of the extensions and the key
`dis:ribution, data origin authentication, and transaction and request
`security they provide.
`
`Sec:ion 3 discusses the KEY resource record, its structure, and use
`in DNS responses.
`These resource records represent the public keys
`of entities named in the DNS and are used for key distribution.
`
`
`
`its
`Sec:ion 4 discusses the SIG digital signature resource record,
`structure, and use in DNS responses. These resource records are used
`to authenticate other resource records in the DNS and optionally to
`autienticate DNS transactions and requests.
`
`Sec:ion 5 discusses the NXT resource record (RR) and its use in DNS
`responses including full and incremental zone transfers.
`The NXT RR
`permits authenticated denial of the existence of a name or of an RR
`type for an existing name.
`
`
`
`Section 6 discusses how a resolver can be configured with a starting
`key or keys and proceed to securely resolve DNS requests.
`Interactions between resolvers and servers are discussed for various
`combinations of security aware and security non—aware.
`Two
`additional DNS header bits are defined for signaling between
`resolvers and servers.
`
`Sec:ion 7 describes the ASCII representation of the security resource
`records for use in master files and elsewhere.
`
`Sec:ion 8 defines the canonical form and order of RRs for DNS
`security purposes.
`
`Sec:ion 9 defines levels of conformance for resolvers and servers.
`
`Sec:ion 10 provides a few paragraphs on overall security
`considerations.
`
`
`
`Sec:ion 11 specified IANA considerations for allocation of additional
`values of paramters defined in this document.
`
`
`Eastlake
`
`RFC 2535
`
`Standards Track
`
`
`DNS Security Extensions
`
`[Page 4]
`
`March 1999
`
`Appendix A gives details of base 64 encoding which is used in the
`file representation of some RRs defined in this document.
`
`Appendix B summarizes changes between this memo and RFC 2065.
`
`Appendix C specified how to calculate the simple checksum used as a
`key tag in most SIG RRs.
`
`The key words "MUST",
`
`"MUST NOT",
`
`"SHALL",
`
`"SHALL NOT",
`
`
`
`
`"R4QUIR4D",
`
`Petitioner Apple Inc. - Exhibit 1082, p. 4
`fi le:///C :/Users/j g01‘d007/AppData/Local/Temp/Low/D3TZ87LX.htm
`10/23/2014
`
`Apple V. VirnetX, et a1., IPR2014—00237 and IPR2014—OO238
`
`Apple v. VirnetX, et al., IPR2014-00237 and IPR2014-00238
`Petitioner Apple Inc. - Exhibit 1082, p. 4
`
`
`
`
`
`
`
`
`"MAY", and "OPTIONAL"
`"R<COMMEND<D",
`"SHOULD NOT",
`"SHOULD",
`document are to be interpreted as described in [RFC2119].
`
`in this
`
`
`2. Overview of the DNS Extensions
`
`The Domain Name System (DNS) protocol security extensions provide
`three distinct services: key distribution as described in Section 2.2
`below, data origin authentication as described in Section 2.3 below,
`and transaction and request authentication, described in Section 2.4
`below.
`
`
`Special considerations related to "time to live", CNAMEs, and
`delegation points are also discussed in Section 2.3.
`
`2.1 Services Not Provided
`
`It is part of the design philosophy of the DNS that the data in it is
`public and that the DNS gives the same answers to all inquirers.
`Following this philosophy, no attempt has been made to include any
`sort of access control lists or other means to differentiate
`inquirers.
`
`No effort has been made to provide for any confidentiality for
`
`queries or responses.
`(This service may be available via IPSEC [RFC
`2401], TLS, or other security protocols.)
`
`Protection is not provided against denial of service.
`
`2.2 Key Distribution
`
`A resource record format is defined to associate keys with DNS names.
`This permits the DNS to be used as a public key distribution
`mechanism in support of DNS security itself and other protocols.
`
`
`
`The syntax of a KEY resource record (RR)
`
`is described in Section 3.
`
`the actual public key
`It includes an algorithm identifier,
`parameter(s), and a variety of flags including those indicating the
`type of entity the key is associated with and/or asserting that there
`is no key associated with that entity.
`
`
`Eastlake
`
`RFC 2535
`
`Standards Track
`
`
`DNS Security Extensions
`
`[Page 5]
`
`March 1999
`
`Under conditions described in Section 3.5, security aware DNS servers
`
`will automatically attempt to return KEY resources as additional
`information, along with those resource records actually requested,
`minimize the number of queries needed.
`
`to
`
`2.3 Data Origin Authentication and Integrity
`
`Authentication is provided by associating with resource record sets
`(RRsets
`[RFC 2181])
`in the DNS cryptographically generated digital
`signatures. Commonly,
`there will be a single private key that
`authenticates an entire zone but there might be multiple keys for
`different algorithms, signers, etc. If a security aware resolver
`reliably learns a public key of the zone, it can authenticate,
`for
`
`Petitioner Apple Inc. - Exhibit 1082, p. 5
`file:///C :/Users/j gord007/AppData/Local/Temp/Low/D3TZ87LX.htm
`10/23/2014
`
`Apple V. VirnetX, et a1., IPR2014-00237 and IPR2014-00238
`
`Apple v. VirnetX, et al., IPR2014-00237 and IPR2014-00238
`Petitioner Apple Inc. - Exhibit 1082, p. 5
`
`
`
`The
`that it is properly authorized.
`signed data read from that zone,
`most secure implementation is for the zone private key(s)
`to be kept
`off—line and used to re—sign all of the records in the zone
`periodically. However,
`there are cases,
`for example dynamic update
`[RFCs 2136, 2137], where DNS private keys need to be on—line [RFC
`2541].
`
`The data origin authentication key(s) are associated with the zone
`and not with the servers that store copies of the data. That means
`compromise of a secondary server or, if the key(s) are kept off line,
`even the primary server for a zone, will not necessarily affect the
`degree of assurance that a resolver has that it can determine whether
`data is genuine.
`
`A resolver could learn a public key of a zone either by reading it
`from the DNS or by having it staticly configured.
`To reliably learn
`a public key by reading it from the DNS,
`the key itself must be
`signed with a key the resolver trusts. The resolver must be
`configured with at least a public key which authenticates one zone as
`a starting point. From there, it can securely read public keys of
`other zones, if the intervening zones in the DNS tree are secure and
`their signed keys accessible.
`
`Adding data origin authentication and integrity requires no change to
`
`the "on-the—wire" DNS protocol beyond the addition of the signature
`resource type and th k y r sourc
`typ
`n
`ded for key distribution.
`(Data non—existence authentication also requires the NXT RR as
`described in 2.3.2.) This service can be supported by existing
`resolver and caching server implementations so long as they can
`support
`the additional resource types (see Section 9). The one
`
`exception is that CNAME referrals in a secure zone can not be
`authenticated if they are from non—security aware servers (see
`Section 2.3.5).
`
`
`Eastlake
`
`RFC 2535
`
`Standards Track
`
`
`DNS Security Extensions
`
`{Page 6]
`
`March 1999
`
`
`If signatur 8 ar
`3 parat ly r tri v d and verified when retrieving
`the information they authenticate,
`there will be more trips to the
`server and performance will suffer. Security aware servers mitigate
`that degradation by attempting to send the signature(s) needed (see
`Section 4.2).
`
`2.3.1 The SIG Resource Record
`
`is described in
`The syntax of a SIG resource record (signature)
`Section 4.
`It cryptographicly binds the RRset being signed to the
`signer and a validity interval.
`
`
`
`Every name in a secured zone will have associated with it at least
`one SIG resource record for
`ach r sourc
`typ
`und r that name except
`for glue address RRs and delegation point NS RRs.
`A security aware
`server will attempt to return, with RRs retrieved,
`the corresponding
`SIGs.
`If a server is not security aware,
`the resolver must retrieve
`
`Petitioner Apple Inc. - Exhibit 1082, p. 6
`file:///C:/Users/jg0rd007/AppData/Local/Temp/Low/D3TZ87LX.htm
`10/23/2014
`
`Apple V. VirnetX, et a1., IPR2014-00237 and IPR2014-00238
`
`Apple v. VirnetX, et al., IPR2014-00237 and IPR2014-00238
`Petitioner Apple Inc. - Exhibit 1082, p. 6
`
`
`
`all the SIG records for a name and select the one or ones that sign
`the resource record set(s) that resolver is interested in.
`
`2.3.2 Authenticating Name and Type Non—existence
`
`The above security mechanism only provides a way to sign existing
`RRsets in a zone.
`"Data origin" authentication is not obviously
`provided for the non—existence of a domain name in a zone or the
`non—existence of a type for an existing name. This gap is filled by
`the NXT RR which authenticatably asserts a range of non~existent
`names in a zone and the non—existence of types for the existing name
`just before that range.
`
`Section 5 below covers the NXT RR.
`
`2.3.3 Special Considerations With Timeeto—Live
`
`A digital signature will fail to verify if any change has occurred to
`the data between the time it was originally signed and the time the
`signature is verified. This conflicts with our desire to have the
`time—to—live (TTL) field of resource records tick down while they are
`cached.
`
`This could be avoided by leaving the time—to—live out of the digital
`signature, but that would allow unscrupulous servers to set
`arbitrarily long TTL values undetected.
`Instead, we include the
`"original" TTL in the signature and communicate that data along with
`the current TTL. Unscrupulous servers under this scheme can
`manipulate the TTL but a security aware resolver will bound the TTL
`value it uses at the original signed value. Separately, signatures
`include a signature inception time and a signature expiration time. A
`
`Eastlake
`
` RFC 2535
`
`Standards Track
`
`
`DNS Security Extensions
`
`[Page 7]
`
`March 1999
`
`resolver that knows the absolute time can determine securely whether
`a signature is in effect.
`It is not possible to rely solely on the
`signature expiration as a substitute for the TTL, however, since the
`TTL is primarily a database consistency mechanism and non—security
`aware servers that depend on TTL must still be supported.
`
`2.3.4 Special Considerations at Delegation Points
`
`DNS security would like to View each zone as a unit of data
`completely under the control of the zone owner with each entry
`(RRset) signed by a special private key held by the zone manager.
`But the DNS protocol views the leaf nodes in a zone, which are also
`the apex nodes of a subzone (i.e., delegation points), as "really"
`belonging to the subzone.
`These nodes occur in two master files and
`might have RRs signed by both the upper and lower zone's keys. A
`retrieval could get a mixture of these RRs and SIGs, especially since
`one server could be serving both the zone above and below a
`delegation point.
`[RFC 2181]
`
`
`for every
`There MUST be a zone KEY RR, signed by its superzone,
`subzone if the superzone is secure. This will normally appear in the
`
`Petitioner Apple Inc. - Exhibit 1082, p. 7
`file:///C :/Users/j gord007/AppData/Local/Temp/Low/D3TZ87LX.htm
`10/23/2014
`
`Apple V. VirnetX, et a1., IPR2014-00237 and IPR2014-00238
`
`Apple v. VirnetX, et al., IPR2014-00237 and IPR2014-00238
`Petitioner Apple Inc. - Exhibit 1082, p. 7
`
`
`
`in the case
`subzone and may also be included in the superzone. But,
`of an unsecured subzone which can not or will not be modified to add
`
`any security RRs,
`a KEY declaring the subzone to be unsecured MUST
`appear with the superzone signature in the superzone, if the
`superzone is secure. For all but one other RR type :he data from the
`subzone is more authoritative so only the subzone KEY RR should be
`signed in the superzone if it appears there. The NS and any glue
`address RRs SHOULD only be signed in the subzone. Tie SOA and any
`other RRs that have the zone name as owner should appear only in the
`subzone and thus are signed only there. The NXT RR :ype is the
`exceptional case that will always appear differently and
`authoritatively in both the superzone and subzone, if both are
`secure, as described in Section 5.
`
`
`
`2.3.5 Special Considerations wi:h CNAM
`
` L‘J
`
`There is a problem when security related RRs with the same owner name
`
`as a CNAME RR are retrieved from a non—securi:y—aware server.
`In
`particular, an initial retrieval for the CNAME or any other :ype may
`
`not retrieve any associated SIG, KEY, or NXT RR. For retrieved types
`other than CNAME, it will re:rieve that type at the target name of
`
`
`the CNAME (or Ciain of CNAMEs) and will also return the CNAME.
`In
`particular, a specific retrieval for type SIG will not get tie SIG,
`if any, at the original CNA_E domain name but rather a SIG a: the
`target name.
`
`
`
`
`
`
`
`
`
`
`Eastlake
`
`RFC 2535
`
`Standards Track
`
`
`DNS Security Extensions
`
`[Page 8]
`
`March 1999
`
`Security aware servers must be used to securely CNAME in DNS.
`1.
`Security aware servers MUST (1) allow KEY, SIG, and
`XT RRs along
`
`with CNAME RRs,
`(2) suppress CNAME processing on retrieval of these
`
`
`types as well as on retrieval of
`:he type CNAME, and (3)
`1.
`
`automatically return SIG RRs authentica:ing the CNAME or CNAMEs
`encountered in resolving a query. This is a change from the previous
`DNS standard [RFCs 1034/1035] which prohibited any other RR type at a
`
`node where a CNAME RR was present.
`
`
`
`
`
`2.3.6 Signers Other Than The Zone
`
`There are cases where the signer in a SIG resource record is other
`than one of the private key(s) used to authenticate a zone.
`
`(or future requests
`One is for support of dynamic update {RFC 2136]
`which require secure authentication) where an entity is permitted to
`authenticate/update its records [RFC 2137] and the zone is operating
`in a mode where the zone key is not on line. The public key of the
`entity must be present in the DNS and be signed by a zone level key
`but the other RR(s) may be signed with the entity's key.
`
`A second case is support of transaction and request authentication as
`described in Section 2.4.
`
`In additions, signatures can be included on resource records within
`
`Petitioner Apple Inc. - Exhibit 1082, p. 8
`file:///C:/Users/jgordoO7/AppData/Local/Temp/Low/D3TZS7LX.htm
`10/23/2014
`
`Apple V. VirnetX, et a1., IPR2014-OO237 and IPR2014-OO238
`
`Apple v. VirnetX, et al., IPR2014-00237 and IPR2014-00238
`Petitioner Apple Inc. - Exhibit 1082, p. 8
`
`
`
`the DNS for use by applications other than DNS. DNS related
`signatures authenticate that data originated with the authority of a
`zone owner or that a request or transaction originated with the
`relevant entity. Other signatures can provide other types of
`assurances.
`
`2.4 DNS Transaction and Request Authentication
`
`
`The data origin authentication service described above protects
`retrieved resource records and th non— xist nc of r sourc
`records
`but provides no protection for DNS requests or for message headers.
`
`there is little that
`If header bits are falsely set by a bad server,
`can be done. However, it is possible to add transaction
`authentication.
`Such authentication means that a resolver can be
`sure it is at least getting messages from the server it thinks it
`queried and that the response is from the query it sent (i.e.,
`that
`these messages have not been diddled in transit). This is
`accomplished by optionally adding a special SIG resource record at
`the end of the reply which digitally signs the concatenation of the
`server's response and the resolver's query.
`
`Eastlake‘
`
` RFC 2535
`
`Standards Track
`
`
`DNS Security Extensions
`
`[Page 9]
`
`March 1999
`
`Requests can also be authenticated by including a special SIG RR at
`the end of the request. Authenticating requests serves no function
`in older DNS servers and requests with a non—empty additional
`information section produce error returns or may even be ignored by
`many of them. However,
`this syntax for signing requests is defined as
`a way of authenticating secure dynamic update requests [RFC 2137] or
`future requests requiring authentication.
`
`The private keys used in transaction security belong to the entity
`composing the reply, not
`to the zone involved. Request
`authentication may also involve the private key of the host or other
`entity composing the request or other private keys depending on the
`request authority it is sought to establish. The corresponding public
`key(s) are normally stored in and retrieved from the DNS for
`verification.
`
`Because requests and replies are highly variable, message
`authentication SIGs can not be pre—calculated.
`Thus it will be
`necessary to keep the private key on—line,
`for example in software or
`in a directly connected piece of hardware.
`
`
`
`3. The KEY Resource Record
`
`
`
`is used to store a public key that is
`The KEY resource record (RR)
`associated with a Domain Name System (DNS) name. This can be the
`public key of a zone,
`a user, or a host or other end entity. Security
`aware DNS implementations MUS" be designed to handle at least two
`simultaneously valid keys of the same type associated with the same
`name.
`
`
`
`Petitioner Apple Inc. - Exhibit 1082, p. 9
`file:///C:/Users/j gord007/AppData/Local/Temp/Low/D3TZ87LX.htm
`10/23/2014
`
`Apple V. VirnetX, et a1., IPR2014-00237 and IPR2014-00238
`
`Apple v. VirnetX, et al., IPR2014-00237 and IPR2014-00238
`Petitioner Apple Inc. - Exhibit 1082, p. 9
`
`
`
`
`The type number for the KEY RR is 25.
`
`
`like any other RR, authenticated by a SIG RR.
`A KEY RR is,
`must be signed by a zone level key.
`
`
`KEY RRs
`
`3.1 KEY RDATA format
`
`
`the
`The RDATA for a KEY RR consists of flags, a protocol octet,
`algorithm number octet, and the public key itself.
`The format is as
`follows:
`
`
`
`Eastlake
`
`RFC 2535
`
`Standards Track
`
`DNS Security Extensions
`
`[Page 10]
`
`March 1999
`
`2 2 2 2 2 2 3 3
`1 2 2 2 2
`1
`1
`1
`1
`1
`1
`1
`1
`1
`0
`1 2 3 4 5
`6 7
`8
`9
`O
`1
`2 3 4
`5
`6
`7
`8
`9
`0
`1 2 3
`4 5 6 7
`8
`9
`0
`1
`
`:— — -1 :
`— —+—
`—+—+
`~«— :
`:—+
`+— —
`:
`~—~
`: + +—e
`:
`
`+
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`|
`:— —+
`
`flags
`~+— _
`:— —~—:
`
`protocol
`: ~-~— — —+—:
`:—»—+
`
`algorithm |
`—+—+
`:
`—+
`
`—+—
`
`/
`l
`/
`/
`/
`/
`
`+ :
`:
`:—:—+—+
`:
`:
`+—:
`:
`:-:—+ :
`:—+—:
`:—+—+
`:
`:—+—:
`:
`+—+
`:
`:—+—|
`
`public key
`
`The KEY RR is not intended for storage of certificates and a separate
`certificate RR has been developed for that purpose, defined in [RFC
`2538].
`
`
`The meaning of the KEY RR owner name, flags, and protocol octet are
`described in Sections 3.1.1 through 3.1.5 below.
`The flags and
`algorithm must be examined before any data following the algorithm
`octet as they control the existence and format of any following data.
`r"he algorithm and public key fields are described in Section 3.2.
`
`"he format of the public key is algorithm dependent.
`
`
`KEY RRs do not specify their validity period but their authenticating
`IG RR(s) do as described in Section 4 below.
`
`3.1.1 Object Types, DNS Wames, and Keys
`
`The public key in a KEY RR is for the object named in the owner name.
`
`For
`A DNS name may refer :0 three different categories of things.
`example,
`foo.host.exanple could be (1)
`a zone,
`(2)
`a host or other
`end entity , or
`(3)
`the mapping into a DNS name of the user or
`account foo@host.example. Thus,
`there are flag bits, as described
`below,
`in the KEY RR :0 indicate with which of these roles the owner
`
`
`
`
`Petitioner Apple Inc. - Exhibit 1082, p. 10
`fi le:///C :/Users/jg0rd007/AppData/Local/Temp/Low/D3TZ87LX.htm
`10/23/2014
`
`Apple V. VirnetX, et a1., IPR2014—00237 and IPR2014—00238
`
`Apple v. VirnetX, et al., IPR2014-00237 and IPR2014-00238
`Petitioner Apple Inc. - Exhibit 1082, p. 10
`
`
`
`name and public key are associated. Note that an appropriate zone
`
`KEY RR MJST occur at the apex node of a secure zone and zone KEY RRs
`occur only at delegation points.
`
`
`
`3.1.2 The KEY RR Flag Field
`
`In the "flags" field:
`
`5
`4
`3
`2
`1
`O
`9
`8
`7
`6
`5
`4
`3
`2
`1
`0
`
`— —.———
`—— ———
`—— —— :———~—
`———+—
`———+—
`———z
`—
`
`
`
`
`
`
`
`
`
`
`
`
`
`A/C
`_____+_ -
`
`Z
`
`Z
`XT
`_. ___.-__.._
`
`Z
`
`Z
`NAMTYPI
`___._
`+__._
`
`Z
`
`Z
`__._
`
`I
`
`Z
`
`SIG
`
`Bit O and 1 are the key "type" bits whose values have the following
`meanings:
`
`Eastlake
`
`
`
`RFC 2535
`
`DNS Security Extensions
`
`Standards Track
`
`[Page 11]
`
`March 1999
`
`10: Use of the key is prohibited for authentication.
`01: Use of the key is prohibited for confidentiality.
`00: Use of the key for authentication and/or confidentiality
`is permitted. Note that DNS security makes use of keys
`for authentication only. Confidentiality use flagging is
`provided for use of keys in other protocols.
`Implementations not intended to support key distribution
`for confidentiality MAY require that the confidentiality
`use prohibited bit be on for keys they serve.
`11: If both bits are one,
`the "no key" value,
`there is no key
`information and the RR stops after the algorithm octet.
`By the use of this "no key" value,
`a signed KEY RR can
`authenticatably assert that,
`for example,
`a zone is not
`secured.
`See section 3.4 below.
`
`Bits 2 is reserved and must be zero.
`
`a second
`If it is a one,
`Bits 3 is reserved as a flag extension bit.
`16 bit flag field is added after the algorithm octet and
`before the key data. This bit MUST NOT be set unless one or
`more such additional bits have been defined and are non—zero.
`
`Bits 4-5 are reserved and must be zero.
`
`form a field that
`Bits 6 and 7
`have the following meanings:
`
`
`ncod s th nam typ . Fi
`
`ld values
`
`00:
`
`indicates that this is a key associated with a "user" or
`"account" at an end entity, usually a host.
`The coding
`of the owner name is that used for the responsible
`individual mailbox in the SOA and RP RRs: The owner name
`is the user name as the name of a node under the entity
`name.
`For example, "j_random_user" on
`host.subdomain.example could have a public key associated
`
`through a KEY RR with name
`It could be used
`j_random_user.host.subdomain.example.
`in a security protocol where authentication of a user was
`
`Petitioner Apple Inc. - Exhibit 1082, p. 11
`file:///C:/Users/j gord007/AppData/Local/Temp/Low/D3TZS7LX.htm
`10/23/2014
`
`Apple V. VirnetX, et a1., IPR2014—00237 and IPR2014—00238
`
`Apple v. VirnetX, et al., IPR2014-00237 and IPR2014-00238
`Petitioner Apple Inc. - Exhibit 1082, p. 11
`
`
`
`desired. This key might be useful in IP or other
`security for a user level service such a telnet, ftp,
`rlogin, etc.
`indicates that this is a zone key for the zone whose name
`
`is the KEY RR owner name. This is the public key used
`for the primary DNS security feature of data origin
`
`authentication.
`Zone KEY RRs occur only at delegation
`points.
`indicates that this is a key associated with the non—zone
`"entity" whose name is the RR owner name. This will
`commonly be a host but could,
`in some parts of the DNS
`
`01:
`
`10:
`
`Eastlake
`
`RFC 2535
`
`Standards Track
`
`DNS Security Extensions
`
`[Page 12]
`
`March 1999
`
`
`, b
`som oth r typ
`of ntity such as a telephone
`tr
`number
`[RFC 1530} or numeric IP address. This is the
`public key used in connection with DNS request and
`transaction authentication services.
`It could also be
`used in an IP-security protocol where authentication at
`the host, rather than user,
`level was desired, such as
`routing, NTP, etc.
`11: reserved.
`
`Bits 8—11 are reserved and must be zero.
`
`they indicate
`If non—zero,
`Bits 12—15 are the "signatory" field.
`that the key can validly sign things as specified in DNS
`dynamic update [RFC 2137]. Note that zone keys
`(see bits
`6 and 7 above) always have authority to sign any RRs
`in
`the zone regardless of the value of the signatory field.
`
`3.1.3 r"he Protocol Octet
`
`
`
`It is anticipated that keys stored in DNS will be used in conjunction
`with a variety of Internet protocols.
`It is intended that the
`protocol octet and possibly some of the currently unused (must be
`zero) bits in the KEY RR flags as specified in the future will be
`used to indicate a key's validity for different protocols.
`
`The following values of the Protocol Octet are reserved as indicated:
`
`
`VALUE
`
`Protocol
`
`0
`1
`2
`3
`4
`
`-reserved
`TLS
`dnssec
`
`IPSEC
`
`5—254
`255
`
`— available for assignment by IANA
`All
`
`In more detail:
`1 is reserved for use in connection with TLS.
`2 is reserved for use in connection with email.
`
`3 is used for DNS security.
`
`The protocol field SHOULD be set to
`
`Petitioner Apple Inc. - Exhibit 1082, p. 12
`f1 1e:///C:/Users/jg0rdoO7/AppData/Local/Temp/Low/D3TZS7LX.htm
`10/23/2014
`
`Apple V. VirnetX, et a1., IPR2014-00237 and IPR2014-00238
`
`Apple v. VirnetX, et al., IPR2014-00237 and IPR2014-00238
`Petitioner Apple Inc. - Exhibit 1082, p. 12
`
`
`
`this value for zone keys and other keys used in DNS security.
`Implementations that can determine that a {ey is a DNS
`
`security key by the fact that flags label it a zone key or the
`
`signatory flag field is non—zero are NOT R4QUIRiD to check the
`protocol field.
`
`4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol
`and indicates that this key is valid for use in conjunction
`
`
`
`Eastlake
`
` RF