Re: IESG Statement On Oppressive or Exclusionary Language

Fred Baker <fredbaker.ietf@xxxxxxxxx> · Sat, 1 Aug 2020 23:38:48 -0700

Sending again because I left the intended attachment off. My error.

> On Aug 1, 2020, at 11:10 PM, Fred Baker <fredbaker.ietf@xxxxxxxxx> wrote:
> 
> I am following up on the IESG's invitation of comments from the community.
> 
> Attached, please find the result of an grep -w -f ... looking for the words discussed in draft-knodel-terminology:
> 	Master
> 	Slave
> 	Blacklist
> 	Whitelist
> 
> If we are going to enact the proposed policy, I would suggest that we don't try to change RFCs that have already been published, or documents on any kind that derive from another source. The IESG's note comments that these are "complex" to perform, and I would agree with them. I would add that in any context in which a defined term is being used, use the defined term. If you want to change the term, you need to be very clear about it. What we can do that makes sense, IMHO, is not use them in future documents unless their origin is clarified.
> 
> I do take some exception to the statement, made in Mallory's draft, that the terms are "inaccurate". I suspect that the terms are being used in a manner entirely in keeping with their definitions. A "master" controller, per lawinsider.com, is "a controller supervising the operation of several local controllers.". Per yourdictionary.com, a "master program" I "The program in control of the machine.". Looking at several sources ("google is your friend"), a slave changes its configuration to agree with its master, and behaves accordingly. Again, Google is your friend, but a blacklist is according to several definitions a list of identities to be denied access, and a whitelist is a list of identities to be accorded access. If the operation is consistent with ambient definitions, it is not "inaccurate". It may be "other than preferred", but it is not "inaccurate".
> 
> There is no human being identified by the color of their skin or by the relationship between employer and employee; if there were, are are a few other colors and operating modes that would have to be discussed. There is also long historical precedent, stretching back at least to the period prior to Moses leading Israel out of Egypt.
> 
> I have made these comments in hrpc. They were dismissed as originating from a "white male". The issue of exclusionary language in the course of hrpc was reported to the chair of that group, and was not acknowledged. 
> 
>> On Jul 23, 2020, at 9:35 AM, The IESG <iesg@xxxxxxxx> wrote:
>> 
>> The IESG believes the use of oppressive or exclusionary language is 
>> harmful.  Such terminology is present in some IETF documents, including 
>> standards-track RFCs, and has been for many years. It is at odds with 
>> our objective of creating an inclusive and respectful environment in the 
>> IETF, and among readers of our documents.
>> 
>> The IESG realizes that the views of the community about this topic are 
>> not uniform. Determining an actionable policy regarding problematic 
>> language is an ongoing process. We wanted to highlight that initial 
>> discussions about this topic are taking place in the general area (a 
>> draft [1] is slated for discussion in GENDISPATCH [2] at IETF 108).  
>> Updating terminology in previously published RFCs is a complex endeavor, 
>> while making adjustments in the language used in our documents in the 
>> future should be more straightforward. 
>> 
>> The IESG looks forward to hearing more from the community, engaging in 
>> those discussions, and helping to develop a framework for handling this 
>> issue going forward.
>> 
>> [1] https://datatracker.ietf.org/doc/draft-knodel-terminology/
>> [2] https://www.ietf.org/proceedings/108/agenda/agenda-108-gendispatch-03

../bcp/bcp132.txt: confirms mutual possession of a Pairwise Master Key by two
../bcp/bcp16.txt: known as a Master server.
../bcp/bcp16.txt: known as a Slave Server.
../bcp/bcp195.txt: Session Hash and Extended Master Secret Extension", Work
../bcp/bcp219.txt: Master file: "Master files are text files that contain RRs in text
../bcp/bcp219.txt: from [RFC1035], Section 5) Master files are sometimes called "zone
../bcp/bcp219.txt: Slave server: See "Secondary server".
../bcp/bcp219.txt: Master server: See "Primary server".
../bcp/bcp219.txt: Section 2.1) [RFC2136] defines "primary master" as "Master server
../bcp/bcp219.txt: Master file 14
../bcp/bcp219.txt: Master server 19
../bcp/bcp219.txt: Slave server 19
../bcp/bcp28.txt: Channels. Master's thesis, Ohio University, June 1997.
../fyi/fyi2.txt: o Master SNMP agent which contains an API to communicate
../fyi/fyi2.txt: consists of a plug-in PC card and Master software, a self
../fyi/fyi2.txt: the LAN and frame preprocessing power. The Master
../fyi/fyi22.txt: Master Communications Group
../fyi/fyi32.txt: Hardy, Henry. "The History of the Net." Master's Thesis, School of
../fyi/fyi9.txt: and a Master of Science degree in Operations Research from
../fyi/fyi9.txt: of Los Angeles and obtained a Master's Degree in mathematics
../fyi/fyi9.txt: Joyce K. Reynolds received Bachelor of Arts and Master of
../fyi/fyi9.txt: Bernhard Stockman graduated as Master of Science in Electric
../rfc-index.txt: Master Session Key (EMSK). J. Salowey, L. Dondeti, V. Narayanan, M.
../rfc-index.txt:5807 Definition of Master Key between PANA Client and Enforcement Point.
../rfc-index.txt:6358 Additional Master Secret Inputs for TLS. P. Hoffman. January 2012.
../rfc-index.txt:7627 Transport Layer Security (TLS) Session Hash and Extended Master
../rfc-index.txt:8163 Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP)
../rfc-index.xml: <abstract>This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. [STANDARDS-TRACK]</abstract>
../rfc-index.xml: <title>Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)</title>
../rfc-index.xml: <abstract>The Extensible Authentication Protocol (EAP) defined the Extended Master Session Key (EMSK) generation, but reserved it for unspecified future uses. This memo reserves the EMSK for the sole purpose of deriving root keys. Root keys are master keys that can be used for multiple purposes, identified by usage definitions. This document also specifies a mechanism for avoiding conflicts between root keys by deriving them in a manner that guarantees cryptographic separation. Finally, this document also defines one such root key usage: Domain-Specific Root Keys are root keys made available to and used within specific key management domains. [STANDARDS-TRACK]</abstract>
../rfc-index.xml: <abstract>This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage- specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication, Authorization, and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used. [STANDARDS-TRACK]</abstract>
../rfc-index.xml: <abstract>This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. [STANDARDS-TRACK]</abstract>
../rfc-index.xml: <title>Definition of Master Key between PANA Client and Enforcement Point</title>
../rfc-index.xml: <abstract>This document defines a master key used between a client of the Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. The master key is derived from the Master Session Key of the Extensible Authentication Protocol as a result of successful PANA authentication. The master key guarantees cryptographic independence among enforcement points bootstrapped from PANA authentication across different address families. [STANDARDS-TRACK]</abstract>
../rfc-index.xml: <abstract>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</abstract>
../rfc-index.xml: <title>Additional Master Secret Inputs for TLS</title>
../rfc-index.xml: <abstract>In order to derive a Domain-Specific Root Key (DSRK) from the Extended Master Session Key (EMSK) generated as a side effect of an Extensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached. This document specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain for ERP. [STANDARDS-TRACK]</abstract>
../rfc-index.xml: <kw>Extended Master Session Key</kw>
../rfc-index.xml: <abstract>As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. Cryptographic binding is a facility described in RFC 3748 that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations.</abstract>
../rfc-index.xml: <title>Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension</title>
../rfc-index.xml: <title>Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks</title>
../rfc-index.xml: <abstract>Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks.</abstract>
../rfc-ref.txt:RFC5295 | | Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, DOI 10.17487/RFC5295, August 2008, <https://www.rfc-editor.org/info/rfc5295>.
../rfc-ref.txt:RFC5807 | | Ohba, Y. and A. Yegin, "Definition of Master Key between PANA Client and Enforcement Point", RFC 5807, DOI 10.17487/RFC5807, March 2010, <https://www.rfc-editor.org/info/rfc5807>.
../rfc-ref.txt:RFC6358 | | Hoffman, P., "Additional Master Secret Inputs for TLS", RFC 6358, DOI 10.17487/RFC6358, January 2012, <https://www.rfc-editor.org/info/rfc6358>.
../rfc-ref.txt:RFC7627 | | Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, <https://www.rfc-editor.org/info/rfc7627>.
../rfc-ref.txt:RFC8163 | | Lynn, K., Ed., Martocci, J., Neilson, C., and S. Donaldson, "Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, May 2017, <https://www.rfc-editor.org/info/rfc8163>.
../rfc-ref.txt.new:RFC5295 | | Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, DOI 10.17487/RFC5295, August 2008, <https://www.rfc-editor.org/info/rfc5295>.
../rfc-ref.txt.new:RFC5807 | | Ohba, Y. and A. Yegin, "Definition of Master Key between PANA Client and Enforcement Point", RFC 5807, DOI 10.17487/RFC5807, March 2010, <https://www.rfc-editor.org/info/rfc5807>.
../rfc-ref.txt.new:RFC6358 | | Hoffman, P., "Additional Master Secret Inputs for TLS", RFC 6358, DOI 10.17487/RFC6358, January 2012, <https://www.rfc-editor.org/info/rfc6358>.
../rfc-ref.txt.new:RFC7627 | | Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, <https://www.rfc-editor.org/info/rfc7627>.
../rfc-ref.txt.new:RFC8163 | | Lynn, K., Ed., Martocci, J., Neilson, C., and S. Donaldson, "Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, May 2017, <https://www.rfc-editor.org/info/rfc8163>.
../rfc1008.txt: protocol on a single transport connection. The Slave represents
../rfc1008.txt: the TPMs and the Slave are discussed below in separate sections.
../rfc1008.txt: | |Slave | |Slave | |Slave | |
../rfc1008.txt: to the transport connections or to the Slave as appropriate and they
../rfc1008.txt: the disposition of the TPDU. The Slave gets TPDUs that cannot be
../rfc1008.txt: Slave module reference, virtual data connections to the TPMs to be
../rfc1008.txt: the NSAP, and a data connection to the Slave. There is also a
../rfc1008.txt: connection, variables for managing the Slave and an internal
../rfc1008.txt: description, the Slave processor provides a simple form of output
../rfc1008.txt:1.2.4 Network Slave.
../rfc1008.txt: The primary functions of the Network Slave are to provide downward
../rfc1008.txt: to respond to the receipt of spurious TPDUs. The Slave has an
../rfc1008.txt: to meet current operating conditions. The Slave will concatenate
../rfc1008.txt: by a Slave module, which exerts the "backpressure" on the TPM if its
../rfc1034.txt:files are updated by local system administrators. Master files are text
../rfc1034.txt: - Master files of data.
../rfc1035.txt: 5.3. Master file example 36
../rfc1035.txt: | Master |-------------->| Server | | |Resolver|
../rfc1035.txt: | Master |-------------->| Server | | |Resolver|
../rfc1035.txt: | Master |-------------->| Server | | |Resolver|
../rfc1035.txt:Master files are text files that contain RRs in text form. Since the
../rfc1035.txt:5.3. Master file example
../rfc1059.txt: Master-Slave and Mutual Synchronization", IEEE Trans. Comm.
../rfc115.txt: NIC items and other informational items is the Master Catalog. The
../rfc115.txt: statements coded *z2 NIC in the Master Catalog.
../rfc115.txt: Catalog, which in turn is a subset of a Master Catalog at ARC. The
../rfc115.txt: Master Catalog statement for the document, for later retrieval.
../rfc1247.txt:Master/Slave
../rfc1247.txt: When the two neighbors are exchanging databases, they form a Master
../rfc1247.txt: Slave relationship. The Master sends the first Database Description
../rfc1247.txt: The Master/Slave relationship has been negotiated, and sequence
../rfc1247.txt: Slave. Set the master/slave bit to slave, and set the sequence
../rfc1247.txt: Master.
../rfc1247.txt:Master
../rfc1247.txt:Slave
../rfc1247.txt:Master
../rfc1247.txt:Slave
../rfc1247.txt: The Master/Slave bit. When set to 1, it indicates that the router
../rfc1251.txt: and a Master of Science degree in Operations Research from
../rfc1251.txt: of Los Angeles and obtained a Master's Degree in mathematics
../rfc1251.txt: Joyce K. Reynolds received Bachelor of Arts and Master of
../rfc1276.txt:2. Slave copies of entries which are mastered in another DSA,
../rfc1285.txt: "The number of Non Master PORTs (A, B, or S PORTs)
../rfc1285.txt: "The number of Master PORTs in a node. If the
../rfc1301.txt: 3.3.2. Master quit 30
../rfc1301.txt: | |\ | Master assigns
../rfc1301.txt:3.3.2. Master quit
../rfc1336.txt: and a Master of Science degree in Operations Research from
../rfc1336.txt: of Los Angeles and obtained a Master's Degree in mathematics
../rfc1336.txt: Joyce K. Reynolds received Bachelor of Arts and Master of
../rfc1336.txt: Bernhard Stockman graduated as Master of Science in Electric
../rfc1362.txt: and become the "Slave" of the link. If the "Slave" determines that it
../rfc1362.txt: Request" packet, the "Slave" should issue a disconnect on the
../rfc1362.txt: connection being established. The "Master" of the link (determined
../rfc1362.txt: assigned to the link when the call is fully completed. The "Master"
../rfc1362.txt: packet, the "Slave" MUST turn the packet around, overwrite the router
../rfc1362.txt: After the "Master" has received the "Information Response" and the
../rfc1362.txt: "Slave" has received the "Information Request", standard IPX RIP and
../rfc1362.txt: and the receiver should become the link "Slave".
../rfc1362.txt: option and the "Slave" supports all the options, the "Slave" should
../rfc1362.txt: Type which is to be adopted. The "Master" of the link will then adopt
../rfc1362.txt: determining themselves to be the "Slave" of the link.
../rfc1362.txt: both ends of the link and is calculated by the link "Master".
../rfc1362.txt: The Common Net # is supplied by the link "Master". This number must
../rfc1429.txt: Finally, make sure that the "Master nodes file" is not older
../rfc1470.txt: o Master SNMP agent which contains an API to communicate
../rfc1470.txt: consists of a plug-in PC card and Master software, a self
../rfc1470.txt: the LAN and frame preprocessing power. The Master
../rfc1551.txt: option and the "Slave" supports all the options, the "Slave" MUST set
../rfc1551.txt: workstation determining themselves to be the "Slave" of the link.
../rfc1551.txt: both ends of the link and is calculated by the link "Master". Link
../rfc1551.txt: The Common Net # is supplied by the link "Master". This number must
../rfc1551.txt: themselves to be the "Slave" of the link.
../rfc1551.txt: to support on the link. The Master/Slave election and choice of
../rfc1551.txt: routing type proceeds as described previously. If the Slave detects a
../rfc1583.txt: Master/Slave
../rfc1583.txt: The Master/Slave relationship has been negotiated, and DD
../rfc1583.txt: the router is now Slave. Set the master/slave bit to
../rfc1583.txt: In this case the router is Master.
../rfc1583.txt: Master
../rfc1583.txt: Slave
../rfc1583.txt: Master
../rfc1583.txt: Slave
../rfc1583.txt: ExStart D-D (Seq=x,I,M,Master)
../rfc1583.txt: D-D (Seq=y,I,M,Master) ExStart
../rfc1583.txt: Exchange D-D (Seq=y,M,Slave)
../rfc1583.txt: D-D (Seq=y+1,M,Master) Exchange
../rfc1583.txt: D-D (Seq=y+1,M,Slave)
../rfc1583.txt: D-D (Seq=y+n, Master)
../rfc1583.txt: D-D (Seq=y+n, Slave)
../rfc1583.txt: The Master/Slave bit. When set to 1, it indicates that the
../rfc1608.txt: are physical entities [replicated and refined from the Master
../rfc1634.txt: Master. If the two Extended Node ID fields are equal, a
../rfc1634.txt: the router sending it is the Master.
../rfc1634.txt: the Master.
../rfc1634.txt: option and the "Slave" supports all the options, the "Slave" MUST set
../rfc1634.txt: workstation determining themselves to be the "Slave" of the link.
../rfc1634.txt: both ends of the link and is calculated by the link "Master". Link
../rfc1634.txt: The Common Net # is supplied by the link "Master". This number must
../rfc1634.txt: themselves to be the "Slave" of the link.
../rfc1634.txt: to support on the link. The Master/Slave election and choice of
../rfc1634.txt: routing type proceeds as described previously. If the Slave detects a
../rfc1637.txt: In the NSAP RRs in Master Files and in the printed text in this memo,
../rfc1637.txt: servers can ignore them when reading Master Files. For example, a
../rfc1637.txt:7. Master File Format
../rfc1637.txt: The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
../rfc1637.txt: conforms to Section 5, "Master Files," of RFC 1035. Below are
../rfc1637.txt: examples of the use of these RRs in Master Files to support name-to-
../rfc1637.txt: ;;;;;; Master File for domain nsap.nist.gov.
../rfc1637.txt: ;;;;;; Master File for reverse mapping of NSAPs under the
../rfc1691.txt: images), a Master Document Object is created. When a document
../rfc1691.txt: 1 Document Object number 0 => Master Document Object
../rfc1706.txt: In the NSAP RRs in Master Files and in the printed text in this memo,
../rfc1706.txt: can ignore them when reading Master Files. For example, a printable
../rfc1706.txt:7. Master File Format
../rfc1706.txt: The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
../rfc1706.txt: conforms to Section 5, "Master Files," of RFC 1035. Below are
../rfc1706.txt: examples of the use of these RRs in Master Files to support name-to-
../rfc1706.txt: ;;;;;; Master File for domain nsap.nist.gov.
../rfc1706.txt: ;;;;;; Master File for reverse mapping of NSAPs under the
../rfc1712.txt:5. Master File Format
../rfc1727.txt: Deutsch, P., Master's Thesis, June 1992.
../rfc1803.txt:2. Recommendations for the country-level Master DSA
../rfc1803.txt: * The Master DSA and its shadows should be positioned to minimize the
../rfc1803.txt:2c. Personnel recommendations for the country-level Master DSA
../rfc1876.txt:3. Master File Format
../rfc1898.txt: Master card
../rfc1934.txt:Remote management (Master) start Action
../rfc1934.txt:Remote management (Slave) data Action
../rfc1934.txt:Remote management (Master) data Action
../rfc1934.txt:Remote management (Master) stop Action
../rfc1934.txt: 13 Do Remote management (Master) start Action
../rfc1934.txt: 14 Do Remote management (Slave) data Action
../rfc1934.txt: 15 Do Remote management (Master) data Action
../rfc1934.txt: 17 Do Remote management (Master) stop Action
../rfc1934.txt:15 Do Remote management (Master) start Action
../rfc1934.txt:16 Do Remote management (Slave) data Action
../rfc1934.txt:17 Do Remote management (Master) data Action
../rfc1934.txt:19 Do Remote management (Master) stop Action
../rfc1934.txt:14 Do Remote management (Master) start Action
../rfc1934.txt:15 Do Remote management (Slave) data Action
../rfc1934.txt:16 Do Remote management (Master) data Action
../rfc1934.txt:18 Do Remote management (Master) stop Action
../rfc1941.txt: Master Communications Group
../rfc1943.txt: Master for the DSAs of 117 organizations under c=US. Redundancy for
../rfc1943.txt: Tamarin operated by the InterNIC. Slave updates to this host are
../rfc1996.txt: of "Master," "Slave" and "Stealth" servers, their enumeration in NS
../rfc1996.txt: Slave an authoritative server which uses zone transfer to
../rfc1996.txt: Master any authoritative server configured to be the source
../rfc1996.txt: Primary Master master server at the root of the zone transfer
../rfc1996.txt: 4.5 Zone has Updated on Primary Master
../rfc1996.txt: 4.6 Zone has Updated on a Slave that is also a Master
../rfc1996.txt: different from the Primary Master's due to optional static
../rfc1996.txt: 4.7 Slave Receives a NOTIFY Request from a Master
../rfc1996.txt: 4.8 Master Receives a NOTIFY Response from Slave
../rfc2020.txt: 3.6. Master Mode Operation ..................................... 9
../rfc2020.txt:3.6. Master Mode Operation
../rfc2090.txt: referred to as the Master Client, will be responsible for sending
../rfc2136.txt: and all updates were made as external edits to a zone's Master File.
../rfc2136.txt: "Master," "Slave," and "Primary Master" servers, and their
../rfc2136.txt: Slave an authoritative server that uses AXFR or IXFR to
../rfc2136.txt: Master an authoritative server configured to be the
../rfc2136.txt: Primary Master master server at the root of the AXFR/IXFR
../rfc2167.txt: Master Server: A server where the data is registered for an authority
../rfc2167.txt: Primary Server: See Master Server.
../rfc2167.txt: Secondary Server: See Slave Server.
../rfc2167.txt: Slave Server: A server where the data is replicated from the master
../rfc2167.txt: See Master Server.
../rfc2167.txt: Master Server and Replication.
../rfc2178.txt: Master/Slave
../rfc2178.txt: The Master/Slave relationship has been negotiated, and DD sequence
../rfc2178.txt: the router is now Slave. Set the master/slave bit to
../rfc2178.txt: Master.
../rfc2178.txt: Master
../rfc2178.txt: Slave
../rfc2178.txt: Master
../rfc2178.txt: Slave
../rfc2178.txt: ExStart D-D (Seq=x,I,M,Master)
../rfc2178.txt: D-D (Seq=y,I,M,Master) ExStart
../rfc2178.txt: Exchange D-D (Seq=y,M,Slave)
../rfc2178.txt: D-D (Seq=y+1,M,Master) Exchange
../rfc2178.txt: D-D (Seq=y+1,M,Slave)
../rfc2178.txt: D-D (Seq=y+n, Master)
../rfc2178.txt: D-D (Seq=y+n, Slave)
../rfc2178.txt: The Master/Slave bit. When set to 1, it indicates that the router
../rfc2182.txt: known as a Master server.
../rfc2182.txt: known as a Slave Server.
../rfc2235.txt: Hardy, Henry. "The History of the Net." Master's Thesis, School of
../rfc2244.txt: Example: S: * OK "Master ACAP server is back up"
../rfc2244.txt: S: * NO "Master ACAP server is down, your data may
../rfc2246.txt: generating a Master Secret, which together comprise the primary
../rfc2252.txt: Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29
../rfc2257.txt: 7.2.4 Master Agent Processing of AgentX Responses..............66
../rfc2257.txt:7.2.4. Master Agent Processing of AgentX Responses
../rfc2266.txt: 2.3. Master Mode and Slave Mode ................................ 4
../rfc2266.txt:2.3. Master Mode and Slave Mode
../rfc2297.txt: the Master-Slave nature of the protocol.)
../rfc2308.txt: The Master File format [RFC 1035 Section 5] is extended to include
../rfc2328.txt: Master/Slave
../rfc2328.txt: The Master/Slave relationship has been negotiated, and DD
../rfc2328.txt: the router is now Slave. Set the master/slave bit to
../rfc2328.txt: Master.
../rfc2328.txt: Master
../rfc2328.txt: Slave
../rfc2328.txt: Master
../rfc2328.txt: Slave
../rfc2328.txt: ExStart D-D (Seq=x,I,M,Master)
../rfc2328.txt: D-D (Seq=y,I,M,Master) ExStart
../rfc2328.txt: Exchange D-D (Seq=y,M,Slave)
../rfc2328.txt: D-D (Seq=y+1,M,Master) Exchange
../rfc2328.txt: D-D (Seq=y+1,M,Slave)
../rfc2328.txt: D-D (Seq=y+n, Master)
../rfc2328.txt: D-D (Seq=y+n, Slave)
../rfc2328.txt: The Master/Slave bit. When set to 1, it indicates that the
../rfc2334.txt: | |Master/Slave|
../rfc2334.txt: transitions to the Master/Slave Negotiation State. The Master/Slave
../rfc2334.txt: When the LS's CAFSM reaches the Master/Slave Negotiation State, the
../rfc2334.txt: bits are the M (Master/Slave) bit, the I (Initialization of master)
../rfc2334.txt:2.2.1 Master Slave Negotiation State
../rfc2334.txt: Master/Slave Negotiation State, the role the LS plays in the exchange
../rfc2334.txt: Master/Slave Negotiation State.
../rfc2334.txt: and the CAFSM transitions to the Master/Slave Negotiation State.
../rfc2334.txt: enters the Master/Slave Negotiation state, the CA Sequence Number
../rfc2334.txt: process. This bit is the "Master/Slave bit".
../rfc2338.txt: a virtual router is called the Master, and forwards packets sent to
../rfc2338.txt: in the forwarding responsibility should the Master become
../rfc2338.txt: address(es) associated with a virtual router is called the Master,
../rfc2338.txt: should the Master become unavailable. Any of the virtual router's IP
../rfc2338.txt: single Virtual Router Master are presented. Finally, operational
../rfc2338.txt: Virtual Router Master The VRRP router that is assuming the
../rfc2338.txt: the Master.
../rfc2338.txt: should the current Master fail.
../rfc2338.txt: Master and the additional functionality described below, the protocol
../rfc2338.txt: A simple model of Master election among a set of redundant routers is
../rfc2338.txt: converging to any router as Master. However, there are likely to be
../rfc2338.txt: in an intuitive manner, and guarantee Master convergence to the most
../rfc2338.txt: Once Master election has been performed then any unnecessary
../rfc2338.txt: transitions between Master and Backup routers can result in a
../rfc2338.txt: disruption in service. The protocol should ensure after Master
../rfc2338.txt: of equal or lower preference as long as the Master continues to
../rfc2338.txt: preferential than the current Master. It may be useful to support an
../rfc2338.txt: packet sent by the Master to trigger station learning; 2) trigger a
../rfc2338.txt: message immediately after transitioning to Master to update the
../rfc2338.txt: station learning; and 3) trigger periodic messages from the Master to
../rfc2338.txt: by the Master router to enable bridge learning in an extended LAN.
../rfc2338.txt: To minimize network traffic, only the Master for each virtual router
../rfc2338.txt: attempt to pre-empt the Master unless it has higher priority. This
../rfc2338.txt: always become Master of any virtual router associated with addresses
../rfc2338.txt: it owns. If the Master becomes unavailable then the highest priority
../rfc2338.txt: Backup will transition to Master after a short delay, providing a
../rfc2338.txt: Master to minimize service interruption, and incorporates
../rfc2338.txt: controlled Master transition for typical operational scenarios. The
../rfc2338.txt: Master election. However, the typical scenario assumptions are
../rfc2338.txt: likely to cover the vast majority of deployments, loss of the Master
../rfc2338.txt: router is infrequent, and the expected duration in Master election
../rfc2338.txt: MR = Master Router
../rfc2338.txt: router on the left becomes the Master for virtual router #1 (VRID=1)
../rfc2338.txt: MR = Master Router
../rfc2338.txt: the priority and the state of the Master router associated with the
../rfc2338.txt: current Master has stopped participating in VRRP. This is used to
../rfc2338.txt: trigger Backup routers to quickly transition to Master without having
../rfc2338.txt: to wait for the current Master to timeout.
../rfc2338.txt: router in Master election for this virtual
../rfc2338.txt: for Master router to indicate it is
../rfc2338.txt: Master_Down_Interval Time interval for Backup to declare Master
../rfc2338.txt: router preempts a lower priority Master.
../rfc2338.txt: | Master | | Backup |
../rfc2338.txt: o Transition to the {Master} state
../rfc2338.txt: state of the Master Router.
../rfc2338.txt: o Transition to the {Master} state
../rfc2338.txt:6.4.3 Master
../rfc2338.txt: While in the {Master} state the router functions as the forwarding
../rfc2338.txt: router is acting as Master for virtual router(s) containing addresses
../rfc2338.txt: addresses, the Master virtual router MUST respond to the ARP request
../rfc2338.txt: with the virtual MAC address for the virtual router. The Master
../rfc2338.txt: the current Master router.
../rfc2338.txt: transitions, etc., VRRP may cause there to be more than one Master
../rfc2338.txt: router. If a Master router installs the virtual router MAC address
../rfc2338.txt: ADVERTISEMENTS will be removed from the ring during the Master
../rfc2338.txt: than changing its hardware MAC address. This will prevent a Master
../rfc2356.txt: The SKIP header's source NSID equals 1, indicating that the Master
../rfc2356.txt: Master Key-ID = IPv4 address of the mobile node
../rfc2356.txt: Master Key-ID = none
../rfc2356.txt: Master Key-ID = none
../rfc2356.txt: Master Key-ID = none
../rfc2356.txt: Master Key-ID = none
../rfc2356.txt: Master Key-ID = none
../rfc2356.txt: between the care-of address and the mobile node's Master Key-ID.
../rfc2356.txt: Master Key-ID = none
../rfc2356.txt: Master Key-ID = IPv4 addr of the mobile node
../rfc2356.txt: Master Key-ID = IPv4 address of the mobile node
../rfc2356.txt: Master Key-ID = none
../rfc2356.txt: Master Key-ID = none
../rfc2356.txt: Master Key-ID = none
../rfc2356.txt: Master Key-ID = none
../rfc2356.txt: Master Key-ID = IPv4 address of the mobile node
../rfc2414.txt: Channels. Master's thesis, Ohio University, June 1997.
../rfc2481.txt: Notification (ECN) benefits for TCP", Master's thesis,
../rfc2488.txt: Channels. Master's thesis, Ohio University, June 1997.
../rfc2543.txt: synchronous rendezvous," Master's Thesis CS-TR-96-18, Department
../rfc2582.txt: and Avoidance Schemes. Master's Thesis, MIT, 1995. URL
../rfc2642.txt: 7.2.2 Negotiating the Master/Slave Relationship..... 45
../rfc2642.txt: Master/slave flag
../rfc2642.txt:7.2.2 Negotiating the Master/Slave Relationship
../rfc2642.txt: DB Description (Seq=x, I, M, Master)
../rfc2642.txt: DB Description (Seq=y, I, M, Master)
../rfc2642.txt: DB Description (Seq=y, M, Slave)
../rfc2642.txt: DB Description (Seq=y+1, M, Master)
../rfc2642.txt: DB Description (Seq=y+1, M, Slave)
../rfc2642.txt: DB Description (Seq=y+n, Master)
../rfc2642.txt: DB Description (Seq=y+n, Slave)
../rfc2642.txt: MS-bit (Master/Slave)
../rfc269.txt:file which Master lists as having n pages will take 2048 n bytes of
../rfc2740.txt: The Master/Slave bit. When set to 1, it indicates that the router
../rfc2741.txt: 7.2.5. Master Agent Processing of AgentX Responses.............70
../rfc2741.txt:7.2.5. Master Agent Processing of AgentX Responses
../rfc2741.txt: described in section 7.2.5, "Master Agent Processing of AgentX
../rfc2741.txt: Once the processing described in section 7.2.5, "Master Agent
../rfc2741.txt: "Dispatching AgentX PDUs" and in section 7.2.5, "Master Agent
../rfc2760.txt: Channels. Master's thesis, Ohio University, June 1997.
../rfc2760.txt: Extensions Over Satellite Links. Master's Thesis, Ohio
../rfc2760.txt: Avoidance Schemes. Master's Thesis, MIT, 1995.
../rfc2760.txt: Extended Acknowledgment Interval. Master's Thesis, Ohio
../rfc2787.txt: 2) For "State": M = Master; B = Backup.
../rfc2787.txt: has transitioned to 'Master' state."
../rfc2885.txt: which MGC has read/write capability, and is designated the Master
../rfc2885.txt: parameter is read-only to all but the Master MGC.
../rfc2915.txt: 9. Master File Format . . . . . . . . . . . . . . . . .. . . . . 14
../rfc2915.txt:9. Master File Format
../rfc2926.txt: Master and Shadow Access Points NA
../rfc2967.txt: Predicting Search Times in Index Server Meshes", Master's
../rfc2969.txt: Predicting Search Times in Index Server Meshes", Master's
../rfc3015.txt: which MGC has read/write capability, and is designated the Master
../rfc3015.txt: parameter is read-only to all but the Master MGC.
../rfc3027.txt: Capability Set, Master Slave Determination and
../rfc3040.txt: | Replica Origin | | Master Origin | | Replica Origin |
../rfc3040.txt: | Replica Origin |-----| Master Origin |-----| Replica Origin |
../rfc3116.txt: Master (MS)Bit 1 (both nodes)
../rfc3148.txt: and avoidance schemes". Master's thesis, Massachusetts
../rfc3168.txt: Notification (ECN) benefits for TCP", Master's thesis,
../rfc3261.txt: synchronous rendezvous," Master's Thesis CS-TR-96-18, Department
../rfc3384.txt: 4.5 Single Master.................................................10
../rfc3384.txt: 4.6 Multi-Master..................................................11
../rfc3384.txt: A.11 Failure of the Master in a Master-Slave Replicated Directory..19
../rfc3384.txt: B.5 Some Test Cases for Conflict Resolution in Multi-Master
../rfc3384.txt: B.7 Failover in Single-Master Systems.............................27
../rfc3384.txt: Master Replica - A replica that may be directly updated via LDAP
../rfc3384.txt: operations. In a Master-Slave Replication system, the Master Replica
../rfc3384.txt: Master-Slave, or Single Master Replication - A replication model that
../rfc3384.txt: replicated data. Note that Master-Slave replication can be
../rfc3384.txt: Multi-Master Replication - A replication model where entries can be
../rfc3384.txt: Slave (or Read-Only) Replica - A replica that cannot be directly
../rfc3384.txt:4.5 Single Master
../rfc3384.txt: SM1. A Single Master system SHOULD provide a fast method of
../rfc3384.txt: SM2. The master replica in a Single Master system SHOULD send all
../rfc3384.txt:4.6 Multi-Master
../rfc3384.txt: group, and force a full update from (one of) the Master(s), for
../rfc3384.txt: - Multi-Master replication.
../rfc3384.txt: - Multi-Master replication
../rfc3384.txt: - Multi-Master replication.
../rfc3384.txt:A.11. Failure of the Master in a Master-Slave Replicated Directory
../rfc3384.txt:B.5. Some Test Cases for Conflict Resolution in Multi-Master Replication
../rfc3384.txt:B.7. Failover in Single-Master Systems
../rfc3390.txt: Channels. Master's thesis, Ohio University, June 1997.
../rfc3403.txt: 4.3 Master File Format . . . . . . . . . . . . . . . .. . . . . . 7
../rfc3403.txt:4.3 Master File Format
../rfc3525.txt: which MGC has read/write capability, and is designated the Master
../rfc3525.txt: parameter is read-only to all but the Master MGC.
../rfc3534.txt: Master Olofs Vag 24
../rfc3549.txt: IFF_MASTER Master of a load balancing bundle.
../rfc3549.txt: IFF_SLAVE Slave of a load balancing bundle.
../rfc3579.txt: authenticator to mutually authenticate, and derive a Master Session
../rfc3579.txt: authentication server reside on separate hosts is that the EAP Master
../rfc3619.txt: HELLO_TIMER is the value set by the Master Node.
../rfc3619.txt: FAIL_TIMER is the value set by the Master Node.
../rfc3656.txt: copy of the mailbox database. Slave servers connect to the MUPDATE
../rfc3711.txt: MKI (Master Key Identifier): configurable length, OPTIONAL. The
../rfc3711.txt: The MKI is the Master Key Indicator, and functions according
../rfc3723.txt: [2] Master key generation - such as via MODP Diffie-Hellman
../rfc3742.txt: and Corruption Losses", Master's Thesis, University of
../rfc3746.txt: SA with the CE (master). The FE (Slave) gets the CE certificate
../rfc3748.txt: Master Session Key (MSK)
../rfc3748.txt: Extended Master Session Key (EMSK)
../rfc3748.txt: describe how Master Session Keys (MSKs) and Extended Master
../rfc3748.txt: keying material, such as the Master Session Key (MSK), and
../rfc3748.txt: Extended Master Session Key (EMSK). The MSK is used only for
../rfc3748.txt: derivation MUST export a Master Session Key (MSK) of at least 64
../rfc3748.txt: octets, and an Extended Master Session Key (EMSK) of at least 64
../rfc3768.json:{"draft":"draft-ietf-vrrp-spec-v2-10","doc_id":"RFC3768","title":" Virtual Router Redundancy Protocol (VRRP) ","authors":["R. Hinden, Ed."],"format":["ASCII","HTML"],"page_count":"27","pub_status":"DRAFT STANDARD","status":"DRAFT STANDARD","source":"Virtual Router Redundancy Protocol","abstract":" This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. [STANDARDS-TRACK]","pub_date":"March 2004","keywords":["[VRRP|d]","vrrp","lan","local","area","network","ip","internet","protocol"],"obsoletes":["RFC2338"],"obsoleted_by":["RFC5798"],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC3768","errata_url":null}
../rfc3768.txt: a virtual router is called the Master, and forwards packets sent to
../rfc3768.txt: in the forwarding responsibility should the Master become
../rfc3768.txt: address(es) associated with a virtual router is called the Master,
../rfc3768.txt: should the Master become unavailable. Any of the virtual router's IP
../rfc3768.txt: single Virtual Router Master are presented. Finally, operational
../rfc3768.txt: Virtual Router Master The VRRP router that is assuming the
../rfc3768.txt: the Master.
../rfc3768.txt: should the current Master fail.
../rfc3768.txt: Master and the additional functionality described below, the protocol
../rfc3768.txt: A simple model of Master election among a set of redundant routers is
../rfc3768.txt: converging to any router as Master. However, there are likely to be
../rfc3768.txt: in an intuitive manner, and guarantee Master convergence to the most
../rfc3768.txt: Once Master election has been performed then any unnecessary
../rfc3768.txt: transitions between Master and Backup routers can result in a
../rfc3768.txt: disruption in service. The protocol should ensure after Master
../rfc3768.txt: of equal or lower preference as long as the Master continues to
../rfc3768.txt: preferred over the current Master. It may be useful to support an
../rfc3768.txt: packet sent by the Master to trigger station learning; 2) trigger a
../rfc3768.txt: message immediately after transitioning to Master to update the
../rfc3768.txt: station learning; and 3) trigger periodic messages from the Master to
../rfc3768.txt: by the Master router to enable bridge learning in an extended LAN.
../rfc3768.txt: To minimize network traffic, only the Master for each virtual router
../rfc3768.txt: attempt to preempt the Master unless it has higher priority. This
../rfc3768.txt: always become Master of any virtual router associated with addresses
../rfc3768.txt: it owns. If the Master becomes unavailable then the highest priority
../rfc3768.txt: Backup will transition to Master after a short delay, providing a
../rfc3768.txt: Master to minimize service interruption, and incorporates
../rfc3768.txt: controlled Master transition for typical operational scenarios. The
../rfc3768.txt: Master election. However, the typical scenario assumptions are
../rfc3768.txt: likely to cover the vast majority of deployments, loss of the Master
../rfc3768.txt: router is infrequent, and the expected duration in Master election
../rfc3768.txt: MR = Master Router
../rfc3768.txt: Rtr1 for VRID=1 it will assert itself as Master, with priority=255,
../rfc3768.txt: should fail then the VRRP protocol will transition Rtr2 to Master,
../rfc3768.txt: MR = Master Router
../rfc3768.txt: In this case Rtr2 will assert itself as Master for VRID=2 while Rtr1
../rfc3768.txt: the priority and the state of the Master router associated with the
../rfc3768.txt: current Master has stopped participating in VRRP. This is used to
../rfc3768.txt: trigger Backup routers to quickly transition to Master without having
../rfc3768.txt: to wait for the current Master to timeout.
../rfc3768.txt: in Master election for this virtual router.
../rfc3768.txt: value of 0 (zero) is reserved for Master
../rfc3768.txt: Master_Down_Interval Time interval for Backup to declare Master
../rfc3768.txt: router preempts a lower priority Master.
../rfc3768.txt: | Master | | Backup |
../rfc3768.txt: o Transition to the {Master} state
../rfc3768.txt: state of the Master Router.
../rfc3768.txt: o Transition to the {Master} state
../rfc3768.txt:6.4.3. Master
../rfc3768.txt: While in the {Master} state the router functions as the forwarding
../rfc3768.txt: router is acting as Master for virtual router(s) containing addresses
../rfc3768.txt: addresses, the Master virtual router MUST respond to the ARP request
../rfc3768.txt: with the virtual MAC address for the virtual router. The Master
../rfc3768.txt: the current Master router.
../rfc3768.txt: Address(es) it becomes Master for if it is not the owner. Forwarding
../rfc3768.txt: transitions, etc., VRRP may cause there to be more than one Master
../rfc3768.txt: router. If a Master router installs the virtual router MAC address
../rfc3768.txt: ADVERTISEMENTS will be removed from the ring during the Master
../rfc3768.txt: than changing its hardware MAC address. This will prevent a Master
../rfc3782.txt: Avoidance Schemes", Master's Thesis, MIT, 1995.
../rfc3830.txt: length" is set, this should also be seen as the Master key length
../rfc3830.txt: (otherwise, the SRTP default Master key length is used).
../rfc3833.txt: System Protocol", Master's thesis, Purdue University
../rfc3857.txt: 3.2. Blacklist Alerts ............................... 5
../rfc3857.txt:3.2. Blacklist Alerts
../rfc3881.txt: 5 Master file 2 - System Object
../rfc3881.txt: <xs:appinfo>Master file</xs:appinfo>
../rfc4017.txt: Master Session Key (MSK)
../rfc4017.txt: Extended Master Session Key (EMSK)
../rfc4017.txt: Pairwise Master Key by two parties and distributes a Group Key.
../rfc4017.txt: key derivation MUST export a Master Session Key (MSK) of at
../rfc4017.txt: least 64 octets, and an Extended Master Session Key (EMSK) of at
../rfc4027.txt: end-of-line conventions. Master files are in general ASCII, but
../rfc4072.txt: 4.1.3. EAP-Master-Session-Key AVP ........................19
../rfc4072.txt: | | [EAP-Master-Session-Key] |
../rfc4072.txt: EAP-Master-Session-Key AVP that contains keying material for
../rfc4072.txt: include a Master Session Key (MSK) for protecting the communication
../rfc4072.txt: | EAP-Master-Session-Key |
../rfc4072.txt: | : EAP-Master-Session-Key |
../rfc4072.txt: | | EAP-Master-Session-Key |
../rfc4072.txt: [ EAP-Master-Session-Key ]
../rfc4072.txt:4.1.3. EAP-Master-Session-Key AVP
../rfc4072.txt: The EAP-Master-Session-Key AVP (AVP Code 464) is of type OctetString.
../rfc4072.txt: EAP-Master-Session-Key | 0 | 0-1 |
../rfc4072.txt: o Diameter EAP-Master-Session-Key AVP can be translated to the
../rfc4072.txt: translated to a Diameter EAP-Master-Session-Key AVP. The
../rfc4072.txt: a Diameter EAP-Master-Session-Key AVP.
../rfc4072.txt: 464 for EAP-Master-Session-Key (defined in Section 4.1.3), and
../rfc4072.txt: EAP-Master-Session-Key AVP. For this reason, this specification
../rfc4186.txt: server", "EAP server", "peer", "Silently Discard", "Master Session
../rfc4186.txt: Key (MSK)", and "Extended Master Session Key (EMSK)" in this document
../rfc4186.txt: attributes, and the original Master Key from full authentication is
../rfc4186.txt: used to generate a fresh Master Session Key, as specified in Section
../rfc4186.txt: contributes to the new Master Session Key.
../rfc4186.txt: need to store the following values: Master Key, latest counter value
../rfc4186.txt: On EAP-SIM full authentication, a Master Key (MK) is derived from the
../rfc4186.txt: The Master Key is fed into a Pseudo-Random number Function (PRF)
../rfc4186.txt: EAP-SIM packets, as well as a Master Session Key (MSK) for link layer
../rfc4186.txt: security, and an Extended Master Session Key (EMSK) for other
../rfc4186.txt: authentication, the Master Key is used as the initial secret seed-key
../rfc4186.txt: K_aut (128 bits), Master Session Key (64 bytes), Extended Master
../rfc4186.txt: can be used to generate a new Master Session Key and a new Extended
../rfc4186.txt: Master Session Key. The seed value XKEY' is calculated as follows:
../rfc4186.txt: EAP-Request/SIM/Re-authentication packet. The MK is the Master Key
../rfc4186.txt: two 64-byte chunks and used as the new 64-byte Master Session Key and
../rfc4186.txt: the new 64-byte Extended Master Session Key. Note that because
../rfc4186.txt: Master Session Key and the Extended Master Session key are obtained
../rfc4186.txt: The first 32 bytes of the MSK can be used as the Pairwise Master Key
../rfc4186.txt: When generating the initial Master Key, the hash function is used as
../rfc4186.txt: K_aut), the Master Session Key, and the Extended Master Session Key
../rfc4186.txt: from the Master Session Key, or from the Extended Master Session Key.
../rfc4186.txt: Transient Keys, the Master Session Key, and the Extended Master
../rfc4186.txt: On fast re-authentication, freshness of the Master Session Key and
../rfc4186.txt: the Extended Master Session Key is provided with a counter
../rfc4186.txt: networks. The EAP-SIM Master Session Key, or keys derived from it,
../rfc4186.txt: PEAP include such cryptographic binding. The EAP-SIM Master Session
../rfc4187.txt: server", "EAP server", "peer", "Silently Discard", "Master Session
../rfc4187.txt: Key (MSK)", and "Extended Master Session Key (EMSK)" in this document
../rfc4187.txt: and the original Master Key from full authentication is used to
../rfc4187.txt: generate a fresh Master Session Key, as specified in Section 7.
../rfc4187.txt: contributes to the new Master Session Key.
../rfc4187.txt: the EAP server need to store the following values: Master Key, latest
../rfc4187.txt: On EAP-AKA full authentication, a Master Key (MK) is derived from the
../rfc4187.txt: The Master Key is fed into a Pseudo-Random number Function (PRF),
../rfc4187.txt: EAP-AKA packets, as well as a Master Session Key (MSK) for link layer
../rfc4187.txt: security and an Extended Master Session Key (EMSK) for other
../rfc4187.txt: authentication, the Master Key is used as the initial secret seed-key
../rfc4187.txt: K_aut (128 bits), Master Session Key (64 bytes), Extended Master
../rfc4187.txt: can be used to generate a new Master Session Key and a new Extended
../rfc4187.txt: Master Session Key. The seed value XKEY' is calculated as follows:
../rfc4187.txt: EAP-Request/AKA-Reauthentication packet. The MK is the Master Key
../rfc4187.txt: 64-byte chunks and used as the new 64-byte Master Session Key and the
../rfc4187.txt: new 64-byte Extended Master Session Key. Note that because K_encr
../rfc4187.txt: and K_aut are not derived on fast re-authentication, the Master
../rfc4187.txt: Session Key and the Extended Master Session key are obtained from the
../rfc4187.txt: The first 32 bytes of the MSK can be used as the Pairwise Master Key
../rfc4187.txt: K_aut), the Master Session Keys, and the Extended Master Session Keys
../rfc4187.txt: AKA IK, AKA CK, EAP-AKA K_encr, EAP-AKA K_aut, the Master Session
../rfc4187.txt: Key, or the Extended Master Session Key.
../rfc4187.txt: networks. The EAP-AKA Master Session Key or keys derived from it MAY
../rfc4187.txt: PEAP include such cryptographic binding. The EAP-AKA Master Session
../rfc4194.txt: Master Olofs Vag 24
../rfc4260.txt: Master Session Key (MSK) and Extended Master Session Key (EMSK),
../rfc4260.txt: Pairwise Master Key (PMK) is found between the STA and the AP, which
../rfc4343.txt: In Master Files [STD13] and other human-readable and -writable ASCII
../rfc4343.txt: Originally, DNS data came from an ASCII Master File as defined in
../rfc4343.txt: name tree nodes that appear in a Master File is not defined so that
../rfc4343.txt: the results of inconsistent capitalization in a Master File are
../rfc4346.txt: 8.1. Computing the Master Secret ................................52
../rfc4346.txt:8.1. Computing the Master Secret
../rfc4346.txt: generating a Master Secret, which together comprise the primary
../rfc4413.txt: 5.6. Master Sequence Number .....................................38
../rfc4413.txt:5.6. Master Sequence Number
../rfc4517.txt: Type, LDAP Schema Description, Master And Shadow Access Points,
../rfc4564.txt: Pairwise Master Key (PMK) sharing in the CAPWAP framework. This
../rfc4568.txt: For SRTP, this could be achieved by use of Master Key Identifiers
../rfc4568.txt: - FEC_KEY: Master Key for FEC when the FEC stream is sent
../rfc4568.txt: The third field, which is also OPTIONAL, is the Master Key Identifier
../rfc4568.txt: | Master key length | 128 bits | 128 bits | 128 bits |
../rfc4568.txt: | Master salt length | 112 bits | 112 bits | 112 bits |
../rfc4568.txt: a Master Key Identifier (MKI).
../rfc4641.txt: o Slave servers will need to be able to fetch newly signed zones
../rfc4695.txt: the Universal Real Time System Exclusive message for Master
../rfc4695.txt: System On/Off commands and for the Master Volume and Balance
../rfc4728.txt: 4.6. Blacklist ..................................................33
../rfc4728.txt:4.6. Blacklist
../rfc4746.txt: Extended Master Session Key also generated from the MK and
../rfc4746.txt: Master Key between the client and EAP server from which all other
../rfc4746.txt: Master Session Key generated from the MK and exported by the EAP
../rfc4746.txt: o MK = PAX-KDF-16(AK, "Master Key", E)
../rfc4746.txt: o MSK = PAX-KDF-64(MK, "Master Session Key", E)
../rfc4746.txt: o EMSK = PAX-KDF-64(MK, "Extended Master Session Key", E)
../rfc4763.txt: SMS SAKE Master Secret
../rfc4763.txt: derive other quantities such as the Master Session Key (MSK) and
../rfc4763.txt: Extended Master Session Key (EMSK). Root-Secret-B and Root-Secret-A
../rfc4763.txt: derive a SAKE Master Secret (SMS) and Temporary EAP Keys (TEKs),
../rfc4763.txt: Level 2 contains the key derivation key called the SAKE Master Secret
../rfc4763.txt: Master Session Key (MSK), and Extended MSK (EMSK). TEKs are keys for
../rfc4763.txt: | SAKE Master Secret|<---RAND_S------------->| SAKE Master Secret |
../rfc4763.txt: SMS-A = KDF-16 (Root-Secret-A, "SAKE Master Secret A", RAND_P|RAND_S)
../rfc4763.txt:3.2.6.3. Extended/Master Session Key Derivation
../rfc4763.txt: SMS-B = KDF-16 (Root-Secret-B, "SAKE Master Secret B", RAND_P|RAND_S)
../rfc4763.txt: Session-Key-Block=KDF-128(SMS-B, "Master Session Key", RAND_S|RAND_P)
../rfc4763.txt: EAP-SAKE derives a Master Key (for EAP use) and Master Session Key,
../rfc4763.txt: Master Session Key, and the Extended Master Session Key are
../rfc4764.txt: Extended Master Session Key (EMSK)
../rfc4764.txt: Master Session Key (MSK)
../rfc4771.txt: in the MKI (Master Key Identifier) field of each SRTP packet. This
../rfc4793.txt: o MSK, a Master Session Key, as defined in [1], and
../rfc4793.txt: o EMSK, an Extended Master Session Key, also as defined in [1].
../rfc4811.txt: Master, it may speed up the resynchronization process by immediately
../rfc4851.txt: 5.4. EAP Master Session Key Generation . . . . . . .. . . . . . 35
../rfc4851.txt: authentication and in the generation of Master Session Key (MSK) and
../rfc4851.txt: Extended Master Session Key (EMSK) defined in [RFC3748]. Note that
../rfc4851.txt: inner EAP method(s) may provide Master Session Keys, MSK1..MSKn,
../rfc4851.txt:5.4. EAP Master Session Key Generation
../rfc4851.txt: Extended Master Session Key (EMSK) output from the EAP method are the
../rfc4907.txt: MIT Master's Thesis, 2005.
../rfc4962.txt: confirms mutual possession of a Pairwise Master Key by two
../rfc4981.txt: Distributed Hash Table, Master's Thesis, May 2003.
../rfc4981.txt: case study of Gnutella, Master's Thesis 2001.
../rfc4981.txt: distributed search engine, Master's Thesis
../rfc4981.txt: caching in distributed networks, Master's Thesis, Department of
../rfc4981.txt: Networks, Master's Thesis 2002.
../rfc4995.txt: 4.5. Compression and Master Sequence Number (MSN) ...............13
../rfc4995.txt: MSN Master Sequence Number.
../rfc4995.txt:4.5. Compression and Master Sequence Number (MSN)
../rfc4996.txt: 6.1.1. Master Sequence Number (MSN) . . . . . . . .. . . . . . 19
../rfc4996.txt:6.1.1. Master Sequence Number (MSN)
../rfc4996.txt: the Master Sequence Number (MSN) field. The MSN field is created at
../rfc5012.txt: data could include the United States Postal Service, the Master
../rfc5091.txt: 5.1.1. Master Secret and Public Parameter Generation ......32
../rfc5091.txt: 6.1.1. Generate a Master Secret and Public Parameters .....38
../rfc5091.txt: Public Parameters and a Master Secret ...............41
../rfc5091.txt: Master secret - The master secret is the master key generated and
../rfc5091.txt:5.1.1. Master Secret and Public Parameter Generation
../rfc5091.txt: Parameters and a Master Secret
../rfc5091.txt:6.1.1. Generate a Master Secret and Public Parameters
../rfc5091.txt: Master Secret
../rfc5106.txt: Extended Master Session Key, defined in [2].
../rfc5106.txt: Master Session Key, defined in [2].
../rfc5106.txt: Master Session Key (MSK) and an Extended Master Session Key (EMSK)
../rfc5106.txt: This section describes how the Master Session Key (MSK) and the
../rfc5106.txt: Extended Master Session Key (EMSK) are derived in EAP-IKEv2. It is
../rfc5106.txt: adversary to compute the Master Session Key (MSK) and Extended Master
../rfc5114.txt: (MODP) Diffie-Hellman to compute a pre-Master secret. (Currently,
../rfc5169.txt: derived at the top level, the Master Session Key (MSK) and the
../rfc5169.txt: Extended Master Session Key (EMSK).
../rfc5191.txt: Master Session Key (MSK):
../rfc5216.txt: Master Session Key (MSK)
../rfc5216.txt: Extended Master Session Key (EMSK)
../rfc5225.txt: 6.3.1. Master Sequence Number (MSN) . . . . . . . .. . . . . 21
../rfc5225.txt: The value of this field normally corresponds to the Master
../rfc5225.txt: MSN Master Sequence Number.
../rfc5225.txt:6.3.1. Master Sequence Number (MSN)
../rfc5225.txt: The Master Sequence Number (MSN) field is either taken from a field
../rfc5243.txt: ExStart Empty DD (Seq=x,I,M,Master)
../rfc5243.txt: Empty DD (Seq=y,I,M,Master) ExStart
../rfc5243.txt: Exchange Full DD (Seq=y,M,Slave)
../rfc5243.txt: Full DD (Seq=y+1,M,Master) Exchange
../rfc5243.txt: Full DD (Seq=y+1,Slave)
../rfc5243.txt: Full DD (Seq=y+2, Master)
../rfc5243.txt: Full Empty DD (Seq=y+2, Slave)
../rfc5243.txt: ExStart Empty DD (Seq=x,I,M,Master)
../rfc5243.txt: Empty DD (Seq=y,I,M,Master) ExStart
../rfc5243.txt: Exchange Full DD (Seq=y,M,Slave)
../rfc5243.txt: Full DD (Seq=y+1,Master) Exchange
../rfc5243.txt: Full Empty DD (Seq=y+1, Slave)
../rfc5246.txt: 8.1. Computing the Master Secret ................................64
../rfc5246.txt:8.1. Computing the Master Secret
../rfc5247.txt: Pairwise Master Key by two parties and distributes a Group Key.
../rfc5247.txt: The term AAA-Key is synonymous with Master Session Key (MSK).
../rfc5247.txt: The EAP Master Session Key (MSK), Extended Master Session Key
../rfc5247.txt: Extended Master Session Key (EMSK)
../rfc5247.txt: Master Session Key (MSK)
../rfc5247.txt: Pairwise Master Key (PMK)
../rfc5247.txt: known as the Pairwise Master Key (PMK); the Temporal Key Integrity
../rfc5247.txt: (b) Keying material exported by the EAP method: Master Session Key
../rfc5247.txt: (MSK), Extended Master Session Key (EMSK), Initialization
../rfc5247.txt: MUST export a Master Session Key (MSK) of at least 64 octets, and
../rfc5247.txt: an Extended Master Session Key (EMSK) of at least 64 octets.
../rfc5247.txt: Master Key (PMK). The PMK is only identified by the name of the
../rfc5247.txt: and AAA layer (if present). These include the Master Session Key
../rfc5247.txt: (MSK), Extended Master Session Key (EMSK), Peer-Id(s), Server-Id(s),
../rfc5247.txt: have access to the TLS Master Key identified by the TLS Session-Id,
../rfc5247.txt: [RFC5216]) derive and cache the TLS Master Secret, typically for
../rfc5247.txt: MUST export a Master Session Key (MSK) of at least 64 octets, and
../rfc5247.txt: an Extended Master Session Key (EMSK) of at least 64 octets. EAP
../rfc5247.txt: EAP-Master-Session-Key Attribute-Value Pair (AVP) in clear-text, to
../rfc5281.txt: access point (Master Session Key / Extended Master Session Key
../rfc5295.json:{"draft":"draft-ietf-hokey-emsk-hierarchy-07","doc_id":"RFC5295","title":"Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)","authors":["J. Salowey","L. Dondeti","V. Narayanan","M. Nakhjiri"],"format":["ASCII","HTML"],"page_count":"21","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Handover Keying","abstract":"The Extensible Authentication Protocol (EAP) defined the Extended\r\nMaster Session Key (EMSK) generation, but reserved it for unspecified\r\nfuture uses. This memo reserves the EMSK for the sole purpose of\r\nderiving root keys. Root keys are master keys that can be used for\r\nmultiple purposes, identified by usage definitions. This document\r\nalso specifies a mechanism for avoiding conflicts between root keys\r\nby deriving them in a manner that guarantees cryptographic\r\nseparation. Finally, this document also defines one such root key\r\nusage: Domain-Specific Root Keys are root keys made available to and\r\nused within specific key management domains. [STANDARDS-TRACK]","pub_date":"August 2008","keywords":["[--------]","EAP keying","EMSK","DSRK","DSUSRK","Domain-Specific Key Derivation","Usage-Specific Key Derivation"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC5295","errata_url":"https:\/\/www.rfc-editor.org\/errata\/rfc5295"}
../rfc5295.txt: from an Extended Master Session Key (EMSK)
../rfc5295.txt: Master Session Key (EMSK) generation, but reserved it for unspecified
../rfc5295.txt: two types of keying material: a Master Session Key (MSK) and an
../rfc5295.txt: Extended Master Session Key (EMSK). The EAP specification implicitly
../rfc5295.txt: authenticator, Master Session Key (MSK), Extended Master Session Key
../rfc5296.txt: generating EAP methods: the Master Session Key (MSK) and the Extended
../rfc5296.txt: Re-authentication Master Session Key@xxxxxxxx
../rfc5296.txt: Master Session Key (EMSK)", RFC 5295, August 2008.
../rfc5340.txt: The Master/Slave bit. When set to 1, it indicates that the router
../rfc5412.txt: 7.4.9. Add Blacklist Entry .................................63
../rfc5412.txt: 7.4.10. Delete Blacklist Entry .............................63
../rfc5412.txt: 7.4.11. Add Static Blacklist Entry .........................64
../rfc5412.txt: 7.4.12. Delete Static Blacklist Entry ......................64
../rfc5412.txt:7.4.9. Add Blacklist Entry
../rfc5412.txt: The Add Blacklist Entry message element is used by an AC to add a
../rfc5412.txt: Type: 65 for Add Blacklist Entry
../rfc5412.txt:7.4.10. Delete Blacklist Entry
../rfc5412.txt: The Delete Blacklist Entry message element is used by an AC to delete
../rfc5412.txt: Type: 66 for Delete Blacklist Entry
../rfc5412.txt:7.4.11. Add Static Blacklist Entry
../rfc5412.txt: The Add Static Blacklist Entry message element is used by an AC to
../rfc5412.txt: add a permanent Blacklist Entry on a WTP, ensuring that the WTP no
../rfc5412.txt: Type: 70 for Delete Blacklist Entry
../rfc5412.txt:7.4.12. Delete Static Blacklist Entry
../rfc5412.txt: The Delete Static Blacklist Entry message element is used by an AC to
../rfc5412.txt: Type: 71 for Delete Blacklist Entry
../rfc5418.txt: o PMK - Pairwise Master Key
../rfc5421.txt: Since EAP-FAST-GTC does not generate session keys, the MSKi (Master
../rfc5422.txt: exchanges defined in RFC 4851. The exported EAP Master Session Key
../rfc5433.txt: EMSK: Extended Master Session Key is exported by the EAP method (64
../rfc5433.txt: MK: A session-specific Master Key between the peer and EAP server
../rfc5433.txt: MSK: Master Session Key exported by the EAP method (64 octets).
../rfc5433.txt: During an EAP-GPSK authentication, a Master Key MK, a Session Key SK,
../rfc5447.txt: | EAP-Master-Session-Key |
../rfc5447.txt: | EAP-Master-Session-Key |
../rfc5447.txt: | EAP-Master-Session-Key |
../rfc5448.txt: bits), MSK (Master Session Key, 512 bits), and EMSK (Extended Master
../rfc5448.txt: algorithm, can compute the keys CK' and IK' and, hence, the Master
../rfc5448.txt: change how the Master Key (MK) is calculated in RFC 4187 (it uses CK
../rfc5479.txt: SRTCP message that contains the answerer's SRTP Master Key, rollover
../rfc5507.txt: zone at the Primary Master name server. For some server
../rfc553.txt: Master/instance rectangle: specifies a rectangle in the
../rfc553.txt: Master-Instance rectangles
../rfc5609.txt: retrieve a Master Session Key (MSK) from the EAP entity. If an
../rfc5749.txt: Master Session Key (EMSK) hierarchy previously established between
../rfc5749.txt: method derives a Master Session Key (MSK) and an Extended Master
../rfc5749.txt: Extended Master Session Key (EMSK)", RFC 5295,
../rfc5764.txt: however, they all have the same SRTP Protection Profile and Master
../rfc5764.txt: order of preference. The srtp_mki value contains the SRTP Master Key
../rfc5764.txt: to use the SRTP Master Key Identifier (MKI) field in the SRTP and
../rfc5778.txt: [ EAP-Master-Session-Key ]
../rfc5795.txt: 4.5. Compression and Master Sequence Number (MSN) . .. . . . . . 14
../rfc5795.txt: MSN Master Sequence Number.
../rfc5795.txt:4.5. Compression and Master Sequence Number (MSN)
../rfc5798.json:{"draft":"draft-ietf-vrrp-unified-spec-05","doc_id":"RFC5798","title":"Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6","authors":["S. Nadas, Ed."],"format":["ASCII","HTML"],"page_count":"40","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Virtual Router Redundancy Protocol","abstract":"This memo defines the Virtual Router Redundancy Protocol (VRRP) for\r\nIPv4 and IPv6. It is version three (3) of the protocol, and it is\r\nbased on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in\r\n\"Virtual Router Redundancy Protocol for IPv6\". VRRP specifies an election\r\nprotocol that dynamically assigns responsibility for a virtual router to one\r\nof the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6\r\naddress(es) associated with a virtual router is called the Master, and it\r\nforwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers\r\nare configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers\r\ninfer the address family of the virtual addresses being carried based on the\r\ntransport protocol. Within a VRRP router, the virtual routers in each of the\r\nIPv4 and IPv6 address families are a domain unto themselves and do not\r\noverlap. The election process provides dynamic failover in the forwarding\r\nresponsibility should the Master become unavailable. For IPv4, the\r\nadvantage gained from using VRRP is a higher-availability default\r\npath without requiring configuration of dynamic routing or router\r\ndiscovery protocols on every end-host. For IPv6, the advantage\r\ngained from using VRRP for IPv6 is a quicker switchover to Backup\r\nrouters than can be obtained with standard IPv6 Neighbor Discovery\r\nmechanisms. [STANDARDS-TRACK]","pub_date":"March 2010","keywords":["[--------]"],"obsoletes":["RFC3768"],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC5798","errata_url":"https:\/\/www.rfc-editor.org\/errata\/rfc5798"}
../rfc5798.txt: router is called the Master, and it forwards packets sent to these
../rfc5798.txt: IPv4 or IPv6 addresses. VRRP Master routers are configured with
../rfc5798.txt: failover in the forwarding responsibility should the Master become
../rfc5798.txt: 6.4.3. Master ..............................................24
../rfc5798.txt: address(es) associated with a virtual router is called the Master,
../rfc5798.txt: Master routers are configured with virtual IPv4 or IPv6 addresses,
../rfc5798.txt: responsibility should the Master become unavailable.
../rfc5798.txt: address(es) associated with a virtual router is called the Master and
../rfc5798.txt: Master become unavailable. Any of the virtual router's IPv4
../rfc5798.txt: single Virtual Router Master are presented. Finally, operational
../rfc5798.txt: Virtual Router Master The VRRP router that is assuming the
../rfc5798.txt: it will always become the Master.
../rfc5798.txt: router should the current Master fail.
../rfc5798.txt: VRRP. While providing election of a Virtual Router Master and the
../rfc5798.txt: A simple model of Master election among a set of redundant routers is
../rfc5798.txt: converging to any router as Master. However, there are likely to be
../rfc5798.txt: in an intuitive manner and guarantee Master convergence to the most
../rfc5798.txt: Once Master election has been performed, any unnecessary transitions
../rfc5798.txt: between Master and Backup routers can result in a disruption in
../rfc5798.txt: service. The protocol should ensure after Master election that no
../rfc5798.txt: preference as long as the Master continues to function properly.
../rfc5798.txt: Master becomes available. It may be useful to support an override of
../rfc5798.txt: by the Master to trigger station learning; 2) trigger a message
../rfc5798.txt: immediately after transitioning to the Master to update the station
../rfc5798.txt: learning; and 3) trigger periodic messages from the Master to
../rfc5798.txt: Sub-second detection of Master VRRP router failure is needed in both
../rfc5798.txt: delays might cause a VRRP Backup to conclude that the Master is down,
../rfc5798.txt: and therefore promote itself to Master. Very shortly afterwards, the
../rfc5798.txt: delayed VRRP packets from the Master cause a switch back to Backup
../rfc5798.txt: be possible for a VRRP Master to observe that this situation is
../rfc5798.txt: periodic VRRP messages sent by the Master router to enable bridge
../rfc5798.txt: To minimize network traffic, only the Master for each virtual router
../rfc5798.txt: attempt to preempt the Master unless it has higher priority. This
../rfc5798.txt: always become Master of any virtual router associated with addresses
../rfc5798.txt: it owns. If the Master becomes unavailable, then the highest-
../rfc5798.txt: priority Backup will transition to Master after a short delay,
../rfc5798.txt: Master to minimize service interruption and incorporates
../rfc5798.txt: controlled Master transition for typical operational scenarios. The
../rfc5798.txt: Master election. However, the typical scenario assumptions are
../rfc5798.txt: likely to cover the vast majority of deployments, loss of the Master
../rfc5798.txt: router is infrequent, and the expected duration in Master election
../rfc5798.txt: MR = Master Router
../rfc5798.txt: enabled on Rtr1 for VRID=1, it will assert itself as Master, with
../rfc5798.txt: then the VRRP protocol will transition Rtr2 to Master, temporarily
../rfc5798.txt: will re-assert itself as Master.
../rfc5798.txt: enabled on Rtr1 for VRID=1, it will assert itself as Master, with
../rfc5798.txt: fail, then the VRRP protocol will transition Rtr2 to Master,
../rfc5798.txt: MR = Master Router
../rfc5798.txt: this case, Rtr2 will assert itself as Master for VRID=2 while Rtr1
../rfc5798.txt: this case, Rtr2 will assert itself as Master for VRID=2 while Rtr1
../rfc5798.txt: the priority and the state of the Master router associated with the
../rfc5798.txt: current Master has stopped participating in VRRP. This is used to
../rfc5798.txt: trigger Backup routers to quickly transition to Master without having
../rfc5798.txt: to wait for the current Master to time out.
../rfc5798.txt: Note that higher-priority Master routers with slower transmission
../rfc5798.txt: the higher-priority Master with a slower rate. When this happens, it
../rfc5798.txt: priority Master, it will relinquish mastership.
../rfc5798.txt: router in Master election for this
../rfc5798.txt: reserved for the Master router to
../rfc5798.txt: ADVERTISEMENTS received from the Master
../rfc5798.txt: Master down (centiseconds).
../rfc5798.txt: preempts a lower-priority Master router.
../rfc5798.txt: Master state will accept packets
../rfc5798.txt: | Master | | Backup |
../rfc5798.txt: (145) + Transition to the {Master} state
../rfc5798.txt: state of the Master router.
../rfc5798.txt: (410) + Transition to the {Master} state
../rfc5798.txt:6.4.3. Master
../rfc5798.txt: While in the {Master} state, the router functions as the forwarding
../rfc5798.txt: Note that in the Master state, the Preempt_Mode Flag is not
../rfc5798.txt: (770) * else // new Master logic
../rfc5798.txt: (780) *endif // new Master detected
../rfc5798.txt: (795) endwhile // in Master
../rfc5798.txt: a VRRP router is acting as Master for virtual router(s) containing
../rfc5798.txt: addresses, the Virtual Router Master MUST respond to the ARP request
../rfc5798.txt: router. The Virtual Router Master MUST NOT respond with its physical
../rfc5798.txt: use the same MAC address regardless of the current Master router.
../rfc5798.txt: o When configuring an interface, Virtual Router Master routers
../rfc5798.txt: a VRRP router is acting as Master for virtual router(s) containing
../rfc5798.txt: router IPv6 address, the Virtual Router Master MUST respond to the ND
../rfc5798.txt: virtual router. The Virtual Router Master MUST NOT respond with its
../rfc5798.txt: MAC address regardless of the current Master router.
../rfc5798.txt: When a Virtual Router Master sends an ND Neighbor Solicitation
../rfc5798.txt: message for a host's IPv6 address, the Virtual Router Master MUST
../rfc5798.txt: o When configuring an interface, Virtual Router Master routers
../rfc5798.txt: Note that on a restarting Master router where the VRRP protected
../rfc5798.txt: When a Backup VRRP router has become Master for a virtual router, it
../rfc5798.txt: packets addressed to the IPvX address for which it becomes Master.
../rfc5798.txt: When a virtual router is configured this way and is the Master, it
../rfc5798.txt: should time out based on the rate advertised by the Master; in the
../rfc5798.txt: case of a VRRPv2 Master, this means it must translate the timeout
../rfc5798.txt: should ignore VRRPv2 advertisements from the current Master if it is
../rfc5798.txt: Master is *not* sending VRRPv2 packets: that suggests they don't
../rfc5798.txt: The VRRPv2 Master router interacting with a sub-second VRRPv3 Backup
../rfc5798.txt: It seems possible that a VRRPv3 Master router sending at centisecond
../rfc5798.txt: Master routers with lower frequencies (e.g., 100 centiseconds) until
../rfc5798.txt: behaving as if they are a VRRP Master, creating multiple Masters.
../rfc5798.txt: to give the Master and Backup routers the same prefix delegation in
../rfc5798.txt: the certificates so that Master and Backup routers advertise the same
../rfc5798.txt: set of subnet prefixes. However, the Master and Backup routers
../rfc5798.txt: transitions, etc., VRRP may cause there to be more than one Master
../rfc5798.txt: router. If a Master router installs the virtual router MAC address
../rfc5798.txt: ADVERTISEMENTS will be removed from the ring during the Master
../rfc5798.txt: than changing its hardware MAC address. This will prevent a Master
../rfc5798.txt: o In order to switch to a new Master located on a different bridge
../rfc5798.txt: Token-Ring segment from the previous Master when using source-
../rfc5807.json:{"draft":"draft-ohba-pana-pemk-04","doc_id":"RFC5807","title":"Definition of Master Key between PANA Client and Enforcement Point","authors":["Y. Ohba","A. Yegin"],"format":["ASCII","HTML"],"page_count":"7","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"IETF - NON WORKING GROUP","abstract":"This document defines a master key used between a client of the\r\nProtocol for carrying Authentication for Network Access (PANA) and an\r\nenforcement point, for bootstrapping lower-layer ciphering. The\r\nmaster key is derived from the Master Session Key of the Extensible\r\nAuthentication Protocol as a result of successful PANA\r\nauthentication. The master key guarantees cryptographic independence\r\namong enforcement points bootstrapped from PANA authentication across\r\ndifferent address families. [STANDARDS-TRACK]","pub_date":"March 2010","keywords":["[--------]","protocol for carrying authentication for network access"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC5807","errata_url":null}
../rfc5807.txt: Definition of Master Key between PANA Client and Enforcement Point
../rfc5807.txt: master key is derived from the Master Session Key of the Extensible
../rfc5807.txt:RFC 5807 PaC-EP Master Key March 2010
../rfc5807.txt: 3. PaC-EP Master Key . . . . . . . . . . . . . . . . . .. . . . . . 4
../rfc5807.txt:RFC 5807 PaC-EP Master Key March 2010
../rfc5807.txt: This document defines the PaC-EP Master Key (PEMK) that is used by a
../rfc5807.txt:RFC 5807 PaC-EP Master Key March 2010
../rfc5807.txt: Point), MSK (Master Session Key), PANA Session, and Session
../rfc5807.txt:3. PaC-EP Master Key
../rfc5807.txt: A PEMK (PaC-EP Master Key) is derived from an available MSK. The
../rfc5807.txt:RFC 5807 PaC-EP Master Key March 2010
../rfc5807.txt:RFC 5807 PaC-EP Master Key March 2010
../rfc5807.txt:RFC 5807 PaC-EP Master Key March 2010
../rfc5836.txt: Master Session Key (MSK)
../rfc5925.txt: Master Key Tuple (MKT) configuration or an external, out-of-band MKT
../rfc5925.txt: 3.1. Master Key Tuple ...........................................10
../rfc5925.txt: o KeyID: An unsigned 1-byte field indicating the Master Key Tuple
../rfc5925.txt: outgoing segments: Master Key Tuples (MKTs) and traffic keys. MKTs
../rfc5925.txt:3.1. Master Key Tuple
../rfc5925.txt: A Master Key Tuple (MKT) describes TCP-AO properties to be associated
../rfc5925.txt: o Master key. A byte sequence used for generating traffic keys,
../rfc5931.txt: The Master Key is generated by EAP-pwd. This is a high-entropy
../rfc5931.txt: The Master Session Key exported by EAP-pwd. This is a high-
../rfc5931.txt: The Extended Master Session Key exported by EAP-pwd. This is a
../rfc6.txt: 8. Master Link Clear
../rfc6043.txt: MKI: Master Key Identifier
../rfc6077.txt: in an IEEE 802.11 Wireless LAN", Master Thesis,
../rfc6101.txt: 6.2.1. The Master Secret ...................................37
../rfc6101.txt: 6.2.2. Converting the Master Secret into Keys and
../rfc6101.txt:6.2.1. The Master Secret
../rfc6101.txt:6.2.2. Converting the Master Secret into Keys and MAC Secrets
../rfc6142.txt: Relays and Master Relays SHALL monitor and accept UDP and TCP
../rfc6142.txt: discovery of the Native IP Address of a C12.22 IP Master Relay on the
../rfc6142.txt: For these reasons, all C12.22 IP Relays and Master Relays SHALL
../rfc6142.txt: For IPv6, all C12.22 IP Relays, C12.22 IP Master Relays, and all
../rfc6142.txt: For IPv4, all C12.22 IP Relays, C12.22 IP Master Relays, and all
../rfc6151.txt: [STEV2007] Stevens, M., "On Collisions for MD5", Master's Thesis,
../rfc6168.txt: o Master Servers
../rfc6168.txt: o Slave Servers
../rfc6179.txt: distributed Master VP database (MVPd) that maintains VP-to-companion
../rfc6188.txt: | Master key length | 192 bits |
../rfc6188.txt: | Master salt length | 112 bits |
../rfc6188.txt: | Master key length | 192 bits |
../rfc6188.txt: | Master salt length | 112 bits |
../rfc6188.txt: | Master key length | 256 bits |
../rfc6188.txt: | Master salt length | 112 bits |
../rfc6188.txt: | Master key length | 256 bits |
../rfc6188.txt: | Master salt length | 112 bits |
../rfc6189.txt: ZRTP uses SRTP with no Master Key Identifier (MKI), 32-bit
../rfc6218.txt: for the EAP Master Session Key (MSK) application is set to 0.
../rfc6252.txt: wise Master Key) [RFC5247] using the MPA-SA that is established
../rfc6267.txt: MKI Master Key Identifier
../rfc6295.txt: Real Time System Exclusive message for Master Volume, F0 F7 cc 04
../rfc6295.txt: System On/Off commands and for the Master Volume and Balance
../rfc6358.json:{"draft":"draft-hoffman-tls-master-secret-input-03","doc_id":"RFC6358","title":"Additional Master Secret Inputs for TLS","authors":["P. Hoffman"],"format":["ASCII","HTML"],"page_count":"4","pub_status":"EXPERIMENTAL","status":"EXPERIMENTAL","source":"IETF - NON WORKING GROUP","abstract":"This document describes a mechanism for using additional master\r\nsecret inputs with Transport Layer Security (TLS) and Datagram TLS\r\n(DTLS). This document defines an Experimental Protocol for the Internet\r\ncommunity.","pub_date":"January 2012","keywords":["tls","dtls","datagram tls"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC6358","errata_url":null}
../rfc6358.txt: Additional Master Secret Inputs for TLS
../rfc6358.txt:2. Master Secret Calculation Modifications for TLS and DTLS
../rfc6440.json:{"draft":"draft-ietf-hokey-ldn-discovery-10","doc_id":"RFC6440","title":"The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option","authors":["G. Zorn","Q. Wu","Y. Wang"],"format":["ASCII","HTML"],"page_count":"6","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Handover Keying","abstract":"In order to derive a Domain-Specific Root Key (DSRK) from the\r\nExtended Master Session Key (EMSK) generated as a side effect of an\r\nExtensible Authentication Protocol (EAP) method, the EAP peer must\r\ndiscover the name of the domain to which it is attached.\r\n\r\nThis document specifies a Dynamic Host Configuration Protocol\r\nVersion 6 (DHCPv6) option designed to allow a DHCPv6 server to inform\r\nclients using the EAP Re-authentication Protocol (ERP) EAP method of\r\nthe name of the local domain for ERP. [STANDARDS-TRACK]","pub_date":"December 2011","keywords":["[--------]","re-authentication","handover","LDN","Discovery"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC6440","errata_url":null}
../rfc6440.txt: Extended Master Session Key (EMSK) generated as a side effect of an
../rfc6440.txt: Extended Master Session Key (EMSK)", RFC 5295,
../rfc6443.txt: validation. For example, in the United States of America, the Master
../rfc6503.txt: of her Master thesis. She has also implemented the CCMP prototype
../rfc6508.txt: Master Secret (z_T) - The Master Secret z_T is the master key
../rfc6508.txt: KMS_T chooses its KMS Master Secret, z_T. It MUST randomly select a
../rfc6508.txt: The KMS derives each RSK from an Identifier and its KMS Master
../rfc6508.txt: The KMS Master Secret provides the security for each device
../rfc6509.txt: KMSs MAY update their KMS Master Secret Keys and KMS Master Secret
../rfc6527.txt: 1) For "State": M = Master; B = Backup.
../rfc6538.txt: Identity Protocol", Master thesis, Helsinki University
../rfc6538.txt: Linux", Master thesis, Helsinki University of
../rfc6538.txt: Management", Master thesis, March 2006,
../rfc6582.txt: Avoidance Schemes", Master's Thesis, MIT, June 1995.
../rfc6589.txt: established by the domain, in order to be added to the DNS Whitelist.
../rfc6589.txt: Whitelist automatically, and possibly on a near-real-time basis.
../rfc6589.txt: user host. This also means that a DNS Whitelist can contain both
../rfc6589.txt: query against the whitelist (i.e., the DNS Whitelist).
../rfc6589.txt: | Caching Server 1 - IS NOT ON the DNS Whitelist |
../rfc6589.txt: | Caching Server 2 - IS ON the DNS Whitelist |
../rfc6589.txt: | | | NOT on Whitelist
../rfc6589.txt: | | | IS on Whitelist
../rfc6589.txt: [WL-Ops] Kline, E., "IPv6 Whitelist Operations", Google IPv6
../rfc6618.txt: the EAP-method is key-deriving and creates a shared Master Session
../rfc6621.txt: o Slave operation with an existing unicast MANET routing protocol,
../rfc6630.txt: pre-established Master Session Key
../rfc6630.txt: Similarly, the pre-established Master Session Key (pMSK) is derived
../rfc6630.txt: EAP Early-Authentication Master Session Key@xxxxxxxx
../rfc6630.txt: (USRK) Key Labels" sub-registry of the "Extended Master Session Key
../rfc6630.txt: Extended Master Session Key (EMSK)", RFC 5295,
../rfc6677.txt: the same, the Master Session Key (MSK) from the inner method is
../rfc6678.txt: Master Session Key (MSK), Extended Master Session Key (EMSK),
../rfc6696.txt: key-generating EAP methods: the Master Session Key (MSK) and the
../rfc6696.txt: Re-authentication Master Session Key@xxxxxxxx
../rfc6696.txt: Extended Master Session Key (EMSK)", RFC 5295,
../rfc6697.txt: pre-established Master Session Key.
../rfc6697.txt: Extended Master Session Key (EMSK)", RFC 5295,
../rfc6734.txt: [RFC4072] defines the EAP-Master-Session-Key and EAP-Key-Name AVPs
../rfc6734.txt: Master Session Key (MSK). Also, the EAP Re-authentication Protocol
../rfc6734.txt: Master Session Key [RFC3748].
../rfc6734.txt: re-authentication Root Key, derived from the Extended Master
../rfc6734.txt: A re-authentication Master Session Key [RFC6696].
../rfc6734.txt: Extended Master Session Key (EMSK)", RFC 5295,
../rfc6738.txt: secret, or the Extended Master Session Key (EMSK) as the result of
../rfc6738.txt: Extended Master Session Key (EMSK)", RFC 5295,
../rfc6781.txt: o Slave servers will need to be able to fetch newly signed zones
../rfc6846.txt: 6.1.1. Master Sequence Number (MSN) ........................20
../rfc6846.txt:6.1.1. Master Sequence Number (MSN)
../rfc6846.txt: the Master Sequence Number (MSN) field. The MSN field is created at
../rfc6849.txt: a Master Key Identifier (MKI) or authentication tag; once the
../rfc6867.txt: the re-authentication Master Session Key (rMSK) (see Section 4.6 of
../rfc6867.txt: Extended Master Session Key (EMSK)", RFC 5295,
../rfc6870.txt: 5.2. Master/Slave Mode ..........................................12
../rfc6870.txt: 6.2. PW Standby Notification Procedures in Master/Slave Mode ...15
../rfc6870.txt:5.2. Master/Slave Mode
../rfc6870.txt:6.2. PW Standby Notification Procedures in Master/Slave Mode
../rfc6870.txt: Table 1. PW State Transition Table in Master/Slave Mode
../rfc6942.txt: Master Session Key (EMSK) created during EAP authentication
../rfc6942.txt: answer, as described in Section 6. The re-authentication Master
../rfc6942.txt: Extended Master Session Key (EMSK)", RFC 5295, August
../rfc6952.txt: MKT - Master Key Table
../rfc6952.txt: talks about coordinating keys derived from the Master Key Table (MKT)
../rfc6952.txt: about coordinating keys derived from the Master Key Table (MKT)
../rfc6953.txt: 4.1. Master-Slave White-Space Networks . . . . . . .. . . . . . 9
../rfc6953.txt: Master Device: A device that queries the database, on its own behalf
../rfc6953.txt: Slave Device: A device that queries the database through a master
../rfc6953.txt: | Master |
../rfc6953.txt: | Master | / ( ) \ o
../rfc6953.txt:4.1. Master-Slave White-Space Networks
../rfc6953.txt: |Slave |
../rfc6953.txt: | \| Master | / \
../rfc6953.txt: |Slave | / | Device | \ /
../rfc6953.txt: |Slave | /
../rfc6953.txt: Figure 2: Master-Slave White-Space Network
../rfc6953.txt: 2. Slave devices may power up and associate with the master device
../rfc6953.txt: ( ) |Master| | Slave |--(Air)--| Dev |
../rfc6953.txt: Once the bridged device (Slave Bridge + Wi-Fi) is connected to a
../rfc6953.txt: 1. A bridged slave device (Slave Bridge + Wi-Fi) is connected to a
../rfc6953.txt: | Master node | |-------------|
../rfc6953.txt: | Master node | | | (--/--)
../rfc6953.txt: | Master node | / Link | Other |
../rfc6953.txt: | Master | / \
../rfc6978.txt: In TCP-AO, "a Master Key Tuple (MKT) describes the TCP-AO properties
../rfc7029.json:{"draft":"draft-ietf-emu-crypto-bind-04","doc_id":"RFC7029","title":"Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding","authors":["S. Hartman","M. Wasserman","D. Zhang"],"format":["ASCII","HTML"],"page_count":"19","pub_status":"INFORMATIONAL","status":"INFORMATIONAL","source":"EAP Method Update","abstract":"As the Extensible Authentication Protocol (EAP) evolves, EAP peers\r\nrely increasingly on information received from the EAP server. EAP\r\nextensions such as channel binding or network posture information are\r\noften carried in tunnel methods; peers are likely to rely on this\r\ninformation. Cryptographic binding is a facility described in RFC\r\n3748 that protects tunnel methods against man-in-the-middle attacks.\r\nHowever, cryptographic binding focuses on protecting the server\r\nrather than the peer. This memo explores attacks possible when the\r\npeer is not protected from man-in-the-middle attacks and recommends\r\ncryptographic binding based on an Extended Master Session Key, a new\r\nform of cryptographic binding that protects both peer and server\r\nalong with other mitigations.","pub_date":"October 2013","keywords":["MITM","man-in-the-middle","EMSK crypto binding","Extended Master Session Key","tunnel"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC7029","errata_url":null}
../rfc7029.txt: cryptographic binding based on an Extended Master Session Key, a new
../rfc7029.txt: knowledge of the Master Session Key (MSK) of the inner method. This
../rfc7029.txt: supports an Extended Master Session Key (EMSK). The EMSK is never
../rfc7055.txt: Root Key (CRK). The CRK is derived from the GMSK (GSS-API Master
../rfc7057.txt: peer and EAP authenticator possess the EAP Master Session Key (MSK).
../rfc7069.txt: by utilizing a Master to handle metadata management and several Chunk
../rfc7165.txt: sender generates a symmetric Session Master Key (SMK), encrypts the
../rfc7165.txt: message content (including a per-message Content Master Key), and
../rfc7170.txt: 5.4. EAP Master Session Key Generation . . . . . . . .. . . . . 61
../rfc7170.txt: EAP method providing mutual authentication and an Extended Master
../rfc7170.txt: authentication and in the generation of Master Session Key (MSK) and
../rfc7170.txt: Extended Master Session Key (EMSK) defined in [RFC3748]. Note that
../rfc7170.txt: If an inner method supports export of an Extended Master Session Key
../rfc7170.txt: If an inner method does not support export of an Extended Master
../rfc7170.txt:5.4. EAP Master Session Key Generation
../rfc7170.txt: TEAP authentication assures the Master Session Key (MSK) and Extended
../rfc7170.txt: Master Session Key (EMSK) output from the EAP method are the result
../rfc7170.txt: Extended Master Session Key (EMSK)", RFC 5295, August
../rfc7208.txt: A.3. DNS Blacklist (DNSBL) Style Example .........................56
../rfc7208.txt:A.3. DNS Blacklist (DNSBL) Style Example
../rfc7210.txt: or (for protocols such as TCP-AO) how to construct Master Key
../rfc7268.txt: attempted to utilize the Pairwise Master Key (PMK) derived as a
../rfc7273.txt: "Best Master Clock Algorithm" (BMCA) to determine the active clock
../rfc7273.txt: Slave devices in turn associate the master media clock identifier
../rfc7273.txt: Slave devices recover media clock timing from the clock master
../rfc7273.txt: [RFC7022]. Master clock identifiers not already in base64 format
../rfc7273.txt: Figure 8: RTP Stream with Media Clock Slaved to a Master
../rfc7273.txt: IEEE 1722 Master Device
../rfc7275.txt: 9.1.3.2. Master/Slave Mode ..........................69
../rfc7275.txt: v. Master Mode (0x10)
../rfc7275.txt: using the Master/Slave Mode of operation, with the advertising
../rfc7275.txt: PE acting as Master, per Section 5.2 of [RFC6870].
../rfc7275.txt: vi. Slave Mode (0x20)
../rfc7275.txt: using the Master/Slave Mode of operation, with the advertising
../rfc7275.txt: PE acting as Slave, per Section 5.2 of [RFC6870].
../rfc7275.txt: of the following four options: Master Mode, Slave Mode, Independent
../rfc7275.txt:9.1.3.2. Master/Slave Mode
../rfc7275.txt: RO all of the PEs in the RG are consistently configured as Master or
../rfc7275.txt: Slave.
../rfc7275.txt: Master, then the PE with the best PW Priority (i.e., least numeric
../rfc7309.txt: mode and Master/Slave mode. For the inter-domain four-PW scenario,
../rfc7326.txt: Master Bus Reset (10) G2/S5
../rfc7384.txt: 3.2.4. Rogue Master Attack ..................................9
../rfc7384.txt: P2P TCs by the Master ...............................18
../rfc7384.txt: BMCA Best Master Clock Algorithm [IEEE1588]
../rfc7384.txt: o Master - A clock that generates timing information to other clocks
../rfc7384.txt: o Slave - A clock that receives timing information from a master.
../rfc7384.txt:3.2.4. Rogue Master Attack
../rfc7384.txt: can manipulate the Best Master Clock Algorithm (BMCA) and cause other
../rfc7384.txt:|Master time source attack | + | | || + | + | + | + |
../rfc7384.txt:5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master
../rfc7384.txt: Master election is performed in PTP using the Best Master Clock
../rfc7406.txt: use a key-generating EAP method (that provides a Master Session Key
../rfc7426.txt: Management Functions", Master's thesis, University of
../rfc7476.txt: Master's Thesis, Lulea University of Technology, 2012.
../rfc7525.txt: Session Hash and Extended Master Secret Extension", Work
../rfc7545.txt: Master Device: A device that queries the Database, on its own behalf
../rfc7545.txt: Slave Device: A device that queries the Database through a master
../rfc7545.txt: A Master Device uses PAWS to obtain a schedule of available spectrum
../rfc7545.txt: the Master Device and the Database are connected to the Internet.
../rfc7545.txt: 1. The Master Device obtains (statically or dynamically) the URI
../rfc7545.txt: 2. The Master Device establishes an HTTPS session with the
../rfc7545.txt: 3. The Master Device optionally sends an initialization message to
../rfc7545.txt: 5. The Database may require the Master Device to be registered
../rfc7545.txt: 6. The Master Device sends an available-spectrum request message to
../rfc7545.txt: the Database. The message may be on behalf of a Slave Device
../rfc7545.txt: that made a request to the Master Device.
../rfc7545.txt: 7. If the Master Device is making a request on behalf of a Slave
../rfc7545.txt: Device, the Master Device may verify with the Database that the
../rfc7545.txt: Slave Device is permitted to operate.
../rfc7545.txt: 9. The Master Device may send a spectrum-usage notification message
../rfc7545.txt: notifies the Database what spectrum the Master Device intends to
../rfc7545.txt: it responds by sending the Master Device a spectrum-usage
../rfc7545.txt: informational, the Master Device does not need to process the
../rfc7545.txt: as requiring Master Devices to register with the Database, performing
../rfc7545.txt: Slave Device verification, and sending spectrum-usage notifications.
../rfc7545.txt: For a Master Device that supports multiple rulesets and operates with
../rfc7545.txt: operations for each request by the Master Device:
../rfc7545.txt: 1. The Master Device includes in its request its location and
../rfc7545.txt: 4. The Master Device makes the request again, adding the missing
../rfc7545.txt: 6. The Master Device uses the indicated ruleset to determine how to
../rfc7545.txt: the Master Device of an applicable ruleset, and, for devices with
../rfc7545.txt: Master Device.
../rfc7545.txt: Database. Its use allows the Master Device to determine necessary
../rfc7545.txt: is used by the Master Device when the Database requires it. Note
../rfc7545.txt: the Master Device and the Database.
../rfc7545.txt: the Master Device and the Database. When it is required, the
../rfc7545.txt: Database informs the Master Device via its response to the
../rfc7545.txt: optional for the Master Device and Database. When implemented by
../rfc7545.txt: the Database, its use allows the Master Device to validate Slave
../rfc7545.txt: The Master Device can be provisioned statically (preconfigured) with
../rfc7545.txt: A Master Device SHOULD use the initialization procedure to exchange
../rfc7545.txt: capability information with the Database whenever the Master Device
../rfc7545.txt: initialization response informs the Master Device of specific
../rfc7545.txt: applicable ruleset at the specified location, a Master Device MUST
../rfc7545.txt: preconfigured in a Master Device, they are preconfigured on a per-
../rfc7545.txt: | Master Device | | Spectrum Database |
../rfc7545.txt: The initialization request message allows the Master Device to
../rfc7545.txt: IDs, the Master Device is asking the Database to return a
../rfc7545.txt: other: The Master Device MAY specify additional handshake parameters
../rfc7545.txt: Master Device that supports multiple Databases and rulesets can
../rfc7545.txt: (Section 5.7) to notify the Master Device of a change to the
../rfc7545.txt: the INIT_RESP (Section 4.3.2) message. The Master Device MUST
../rfc7545.txt: Some rulesets require a Master Device to send its registration
../rfc7545.txt: | Master Device | | Spectrum Database |
../rfc7545.txt: deviceDesc: The DeviceDescriptor (Section 5.2) for the Master Device
../rfc7545.txt: Master Device MAY send a union of the registration information
../rfc7545.txt: (Section 5.7) to notify the Master Device of a change to the
../rfc7545.txt: the registration response. The Master Device MUST ignore any
../rfc7545.txt: To obtain the available spectrum from the Database, a Master Device
../rfc7545.txt: | Master Device | | Spectrum Database |
../rfc7545.txt: 1. First, the Master Device sends an available-spectrum request
../rfc7545.txt: 6. If the available-spectrum response indicates that the Master
../rfc7545.txt: Master Device sends the notification message to the Database.
../rfc7545.txt: Even when not required by the Database, the Master Device MAY
../rfc7545.txt: Master Device.
../rfc7545.txt: The procedure for a Master Device to ask for available spectrum on
../rfc7545.txt: behalf of a Slave Device is similar, except that the process is
../rfc7545.txt: initiated by the Slave Device. The device identifier, capabilities,
../rfc7545.txt: MUST be those of the Slave Device, and:
../rfc7545.txt: Master Device is REQUIRED.
../rfc7545.txt: o The "location" field specifying the location of the Slave Device
../rfc7545.txt: is OPTIONAL, since the Slave Device may not have location-sensing
../rfc7545.txt: Although the communication and protocol between the Slave Device and
../rfc7545.txt: Master Device are outside the scope of this document (represented as
../rfc7545.txt: |Slave Device| | Master Device | | Spectrum Database |
../rfc7545.txt: Master Device on its own behalf, the descriptor is that of the
../rfc7545.txt: Master Device, and it is REQUIRED. When the request is made on
../rfc7545.txt: behalf of a Slave Device, the descriptor is that of the Slave
../rfc7545.txt: Master Device on its own behalf, the location is that of the
../rfc7545.txt: Master Device, and it is REQUIRED. When the request is made by
../rfc7545.txt: the Master Device on behalf of a Slave Device, the location is
../rfc7545.txt: that of the Slave Device, and it is OPTIONAL (see also
../rfc7545.txt: capabilities: The Master Device MAY include its DeviceCapabilities
../rfc7545.txt: masterDeviceDesc: When the request is made by the Master Device on
../rfc7545.txt: behalf of a Slave Device, the Master Device MAY provide its own
../rfc7545.txt: masterDeviceLocation: When the request is made by the Master Device
../rfc7545.txt: on behalf of a Slave Device, the Master Device MUST provide its
../rfc7545.txt: response should include generic Slave Device parameters without
../rfc7545.txt: (Master or Slave), so deviceDesc is REQUIRED. The maximum length
../rfc7545.txt: locations to be specified. This enables a portable Master Device,
../rfc7545.txt: Master Device on its own behalf, the descriptor is that of the
../rfc7545.txt: Master Device, and it is REQUIRED. When the request is made on
../rfc7545.txt: behalf of a Slave Device, the descriptor is that of the Slave
../rfc7545.txt: by region. When the request is made by a Master Device on its own
../rfc7545.txt: behalf, the locations are those of the Master Device. When the
../rfc7545.txt: request is made by the Master Device on behalf of a Slave Device,
../rfc7545.txt: the locations are those of the Slave Device (see also
../rfc7545.txt: capabilities: The Master Device MAY include its DeviceCapabilities
../rfc7545.txt: masterDeviceDesc: When the request is made by the Master Device on
../rfc7545.txt: behalf of a Slave Device, the Master Device MAY provide its own
../rfc7545.txt: masterDeviceLocation: When the request is made by the Master Device
../rfc7545.txt: on behalf of a Slave Device, the Master Device MUST provide its
../rfc7545.txt: generic Slave Device parameters without having to specify the
../rfc7545.txt: parameter is missing, the request is for a specific device (Master
../rfc7545.txt: or Slave), so deviceDesc is REQUIRED. The maximum length is 64
../rfc7545.txt: notification is made by a Master Device on its own behalf, the
../rfc7545.txt: location is that of the Master Device and is REQUIRED. When the
../rfc7545.txt: notification is made by a Master Device on behalf of a Slave
../rfc7545.txt: Device, the location is that of the Slave Device and is OPTIONAL
../rfc7545.txt: masterDeviceDesc: When the notification is made by the Master Device
../rfc7545.txt: on behalf of a Slave Device, the Master Device MAY provide its own
../rfc7545.txt: masterDeviceLocation: When the notification is made by the Master
../rfc7545.txt: Device on behalf of a Slave Device, the Master Device MUST include
../rfc7545.txt: A Slave Device needs a Master Device to ask the Database on its
../rfc7545.txt: behalf for available spectrum. Depending on the ruleset, the Master
../rfc7545.txt: Device also must validate with the Database that the Slave Device is
../rfc7545.txt: permitted to operate. When the ruleset allows a Master Device to
../rfc7545.txt: "cache" the available spectrum for a period of time, the Master
../rfc7545.txt: the full Available Spectrum Query component, to validate a Slave
../rfc7545.txt: When validating one or more Slave Devices, the Master Device sends
../rfc7545.txt: other parameters required by the ruleset -- for each Slave Device.
../rfc7545.txt: illustrated in Figure 5, where the Master Device already has a valid
../rfc7545.txt: set of available spectrum for Slave Devices. Note that the
../rfc7545.txt: communication and protocol between the Slave Device and Master Device
../rfc7545.txt: |Slave Device| | Master Device | | Spectrum Database |
../rfc7545.txt: This request is used by a Master Device to determine which Slave
../rfc7545.txt: specifies the list of Slave Devices that are to be validated.
../rfc7545.txt: masterDeviceDesc: The Master Device MAY provide its own descriptor.
../rfc7545.txt: to report the list of Slave Devices and whether each listed device
../rfc7545.txt: and confidentiality between the Master Device and the Database, but
../rfc7545.txt: Database and Master Device MUST follow best current practices defined
../rfc7545.txt: | | | | value is, "Generic Slave", |
../rfc7545.txt: | | | | Slave Device. |
../rfc7545.txt: | | | | value is, "Generic Slave", |
../rfc7545.txt: | | | | Slave Device. |
../rfc7545.txt: Master Device to return device-specific restrictions.
../rfc7545.txt: PAWS is a protocol whereby a Master Device requests a schedule of
../rfc7545.txt: available spectrum at its location (or location of its Slave Devices)
../rfc7545.txt: By using PAWS, the Master Device and the Database expose themselves
../rfc7545.txt: o Accuracy: The Master Device receives incorrect spectrum-
../rfc7545.txt: Master Device or its Slave Devices, such as serial number and
../rfc7545.txt: 1. The Master Device must determine the address of a proper
../rfc7545.txt: 2. The Master Device must connect to the proper Database.
../rfc7545.txt: and the Master Device.
../rfc7545.txt: Master Device to prevent exposing private information.
../rfc7545.txt: 6. For a Slave Device, the spectrum-availability information also
../rfc7545.txt: must be transmitted unmodified and securely between the Master
../rfc7545.txt: Device and the Slave Device.
../rfc7545.txt: the Master Device by presenting a certificate containing that
../rfc7545.txt: If the Master Device has external information as to the expected
../rfc7545.txt: certificate. A Master Device should allow for the fact that a
../rfc7545.txt: can use, the Database cannot enforce that the Master Device uses only
../rfc7545.txt: Depending on a prior relationship between a Database and Master
../rfc7545.txt: o The Database must nominate acceptable CAs, and the Master Device
../rfc7586.txt: proxy is the Master SARP proxy of a set of VLANs and the Backup SARP
../rfc7586.txt: SARP proxy 1 is the Master SARP proxy of VLAN 1 and the Backup SARP
../rfc7586.txt: proxy of VLAN 2, and SARP proxy 2 is the Master SARP proxy of VLAN 2
../rfc7586.txt: The Master SARP proxy updates its Backup SARP proxy with all the ARP
../rfc7586.txt: The Master and the Backup SARP proxies maintain a keepalive
../rfc7586.txt: Master SARP proxy. The failure decision is per VLAN. When the
../rfc7586.txt: Master and the Backup SARP proxies switch over, the Backup SARP proxy
../rfc7586.txt: can use the MAC address of the Master SARP proxy. The Backup SARP
../rfc7586.txt: the Master SARP proxy to update the forwarding tables on the local
../rfc7627.json:{"draft":"draft-ietf-tls-session-hash-06","doc_id":"RFC7627","title":"Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension","authors":["K. Bhargavan, Ed.","A. Delignat-Lavaud","A. Pironti","A. Langley","M. Ray"],"format":["ASCII","HTML"],"page_count":"15","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Transport Layer Security","abstract":"The Transport Layer Security (TLS) master secret is not\r\ncryptographically bound to important session parameters such as the\r\nserver certificate. Consequently, it is possible for an active\r\nattacker to set up two sessions, one with a client and another with a\r\nserver, such that the master secrets on the two sessions are the\r\nsame. Thereafter, any mechanism that relies on the master secret for\r\nauthentication, including session resumption, becomes vulnerable to a\r\nman-in-the-middle attack, where the attacker can simply forward\r\nmessages back and forth between the client and server. This\r\nspecification defines a TLS extension that contextually binds the\r\nmaster secret to a log of the full handshake that computes it, thus\r\npreventing such attacks.","pub_date":"September 2015","keywords":[],"obsoletes":[],"obsoleted_by":[],"updates":["RFC5246"],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC7627","errata_url":null}
../rfc7627.txt: Extended Master Secret Extension
../rfc7627.txt: 4. The Extended Master Secret .......................................6
../rfc7627.txt:4. The Extended Master Secret
../rfc7652.txt: Master Session Key (MSK): A key derived by the partners of a
../rfc7652.txt: Master Session Key (MSK) will be generated. If the PCP client and
../rfc7652.txt: o The Master Session Key (MSK) generated by the EAP method.
../rfc7677.txt: Session Hash and Extended Master Secret Extension",
../rfc7706.txt: 5. In the "Master DNS Servers" dialog box, enter
../rfc7714.txt: Raw Data: The optional variable-length SRTP Master Key
../rfc7714.txt: | Master key length | 128 bits |
../rfc7714.txt: | Master salt length | 96 bits |
../rfc7714.txt: | Master key length | 256 bits |
../rfc7714.txt: | Master salt length | 96 bits |
../rfc7719.txt: Slave server: See secondary server.
../rfc7719.txt: Master server: See primary server.
../rfc7719.txt: Section 2.1). [RFC2136] defines "primary master" as "Master
../rfc7733.txt: EAP Master Session Key shall be derived, as [RFC5191] specifies
../rfc7754.txt: 3.2.1. Blacklist vs. Whitelist Model . . . . . . . .. . . . . 9
../rfc7754.txt:3.2.1. Blacklist vs. Whitelist Model
../rfc7754.txt: Blacklist approaches are often a game of "cat and mouse", where those
../rfc7795.txt: The S-PE that provides PW redundancy MUST work in Slave mode for the
../rfc7795.txt: work in the Master mode, and the T-PEs on the multi-homed side MUST
../rfc7795.txt: Master mode. On the multi-homed side, since both the S-PE and T-PEs
../rfc7795.txt: active. T-PE1 works in Master mode and it would advertise the Active
../rfc7814.txt: router being elected as the VRRP Master is allowed to perform the
../rfc7831.txt: cryptographic keys: a Master Session Key (MSK) and an Extended
../rfc7831.txt: can be used to those that generate a Master Session Key (MSK). Any
../rfc7871.txt: 12.2. Whitelist .................................................24
../rfc7871.txt:12.2. Whitelist
../rfc7919.txt: Session Hash and Extended Master Secret Extension",
../rfc7925.txt: Session Hash and Extended Master Secret Extension",
../rfc7962.txt: School for Design, Doctoral dissertation, Master thesis,
../rfc7966.txt: Diameter client (using the EAP-Master-Session-Key AVP) for the
../rfc7966.txt: Master-Session-Key AVP should benefit from protection against
../rfc8039.txt: /Master\____\___/ \____\________/Slave\
../rfc8039.txt: BMC Best Master Clock [IEEE1588]
../rfc8039.txt: [SLAVEDIV] Mizrahi, T., "Slave Diversity: Using Multiple Paths to
../rfc8110.txt: complete the Diffie-Hellman key exchange and create a Pairwise Master
../rfc8120.txt: Session Hash and Extended Master Secret Extension",
../rfc8163.json:{"draft":"draft-ietf-6lo-6lobac-08","doc_id":"RFC8163","title":"Transmission of IPv6 over Master-Slave\/Token-Passing (MS\/TP) Networks","authors":["K. Lynn, Ed.","J. Martocci","C. Neilson","S. Donaldson"],"format":["ASCII","HTML"],"page_count":"27","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"IPv6 over Networks of Resource-constrained Nodes","abstract":"Master-Slave\/Token-Passing (MS\/TP) is a medium access control method\r\nfor the RS-485 physical layer and is used primarily in building\r\nautomation networks. This specification defines the frame format for\r\ntransmission of IPv6 packets and the method of forming link-local and\r\nstatelessly autoconfigured IPv6 addresses on MS\/TP networks.","pub_date":"May 2017","keywords":[],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC8163","errata_url":null}
../rfc8163.txt: Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks
../rfc8163.txt: Master-Slave/Token-Passing (MS/TP) is a medium access control method
../rfc8163.txt: Master-Slave/Token-Passing (MS/TP) is a Medium Access Control (MAC)
../rfc8163.txt: 1 Poll For Master
../rfc8163.txt: 2 Reply To Poll For Master
../rfc8163.txt: Master Node state machine as specified in [BACnet], Clause 9.
../rfc8163.txt: must implement the Master Node state machine and handle Token, Poll
../rfc8163.txt: For Master, and Reply To Poll For Master control frames. 6LoBAC
../rfc8163.txt: The following parameters are used by the Master Node state machine.
../rfc8169.txt: o A is a boundary clock with its egress port in Master state. Node
../rfc8169.txt: o G is a boundary clock with its ingress port in Slave state. Node
../rfc8169.txt: boundary clock synchronized to a Master Clock and will use the value
../rfc8173.txt: Master clock 1
../rfc8173.txt: Slave clock 2 "
../rfc82.txt: 1) Master collection has all material.
../rfc8216.txt: 4.3.4. Master Playlist Tags ................................25
../rfc8216.txt: 4.3.5. Media or Master Playlist Tags .......................35
../rfc8216.txt: 8.4. Master Playlist ............................................51
../rfc8216.txt: 8.5. Master Playlist with I-Frames ..............................51
../rfc8216.txt: 8.6. Master Playlist with Alternative Audio .....................52
../rfc8216.txt: 8.7. Master Playlist with Alternative Video .....................52
../rfc8216.txt: 8.8. Session Data in a Master Playlist ..........................53
../rfc8216.txt: A Playlist is either a Media Playlist or a Master Playlist. Both are
../rfc8216.txt: A more complex presentation can be described by a Master Playlist. A
../rfc8216.txt: Master Playlist provides a set of Variant Streams, each of which
../rfc8216.txt: identify Media Segments. A Playlist is a Master Playlist if all URI
../rfc8216.txt: either a Media Playlist or a Master Playlist; all other Playlists are
../rfc8216.txt: These tags are allowed in both Media Playlists and Master Playlists.
../rfc8216.txt: every Master Playlist. Its format is:
../rfc8216.txt: A Media Segment tag MUST NOT appear in a Master Playlist. Clients
../rfc8216.txt: Master Playlist tags (Section 4.3.4).
../rfc8216.txt: A Media Playlist tag MUST NOT appear in a Master Playlist.
../rfc8216.txt:4.3.4. Master Playlist Tags
../rfc8216.txt: Master Playlist tags define the Variant Streams, Renditions, and
../rfc8216.txt: Master Playlist tags MUST NOT appear in a Media Playlist; clients
../rfc8216.txt: MUST fail to parse any Playlist that contains both a Master Playlist
../rfc8216.txt: Master Playlist contains two Renditions encoded with the same
../rfc8216.txt: If the Master Playlist is to be made available before all Media
../rfc8216.txt: If the Master Playlist is to be made available before all Media
../rfc8216.txt: GROUP-ID attribute of an EXT-X-MEDIA tag elsewhere in the Master
../rfc8216.txt: GROUP-ID attribute of an EXT-X-MEDIA tag elsewhere in the Master
../rfc8216.txt: GROUP-ID attribute of an EXT-X-MEDIA tag elsewhere in the Master
../rfc8216.txt: in the Master Playlist. Having closed captions in one Variant
../rfc8216.txt: alone, in that it does not apply to a particular URI in the Master
../rfc8216.txt: A Master Playlist that specifies alternative VIDEO Renditions and
../rfc8216.txt: carried in a Master Playlist.
../rfc8216.txt: to be specified in a Master Playlist. This allows the client to
../rfc8216.txt: A Master Playlist MUST NOT contain more than one EXT-X-SESSION-KEY
../rfc8216.txt:4.3.5. Media or Master Playlist Tags
../rfc8216.txt: The tags in this section can appear in either Master Playlists or
../rfc8216.txt: Media Playlists. If one of these tags appears in a Master Playlist,
../rfc8216.txt: it SHOULD NOT appear in any Media Playlist referenced by that Master
../rfc8216.txt: If the EXT-X-INDEPENDENT-SEGMENTS tag appears in a Master Playlist,
../rfc8216.txt: Master Playlist.
../rfc8216.txt: a Master Playlist file that lists each Variant Stream to allow
../rfc8216.txt: Master Playlists describe regular Variant Streams with EXT-X-STREAM-
../rfc8216.txt: o If any Media Playlist in a Master Playlist contains an EXT-X-
../rfc8216.txt: PROGRAM-DATE-TIME tag, then all Media Playlists in that Master
../rfc8216.txt: file so obtained is a Master Playlist, the client can select a
../rfc8216.txt: Variant Stream to load from the Master Playlist.
../rfc8216.txt: A Master Playlist MUST indicate an EXT-X-VERSION of 7 or higher if it
../rfc8216.txt: consider indicating an EXT-X-VERSION of 4 or higher in the Master
../rfc8216.txt:8.4. Master Playlist
../rfc8216.txt:8.5. Master Playlist with I-Frames
../rfc8216.txt:8.6. Master Playlist with Alternative Audio
../rfc8216.txt:8.7. Master Playlist with Alternative Video
../rfc8216.txt:8.8. Session Data in a Master Playlist
../rfc8303.txt: Master Key Tuples (MKTs) for authentication can optionally be
../rfc8352.txt: Master-Slave/Token-Passing (BACnet MS/TP) [MSTP], and Near Field
../rfc8446.txt: 0 -> HKDF-Extract = Master Secret
../rfc8446.txt: Session Hash and Extended Master Secret Extension",
../rfc8446.txt: TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627]
../rfc8446.txt: and earlier versions SHOULD indicate the use of the Extended Master
../rfc8456.txt: 1. Master controller election MUST be completed.
../rfc8471.txt: Session Hash and Extended Master Secret Extension",
../rfc8472.txt: Session Hash and Extended Master Secret Extension",
../rfc8483.txt: on the DMs; instead, it takes place on a central Hidden Master. The
../rfc8483.txt: Master instead of from the Root Server system.
../rfc8483.txt: Hidden Master to the set of DMs, but no DNSSEC operations would be
../rfc8499.txt: Master file: "Master files are text files that contain RRs in text
../rfc8499.txt: from [RFC1035], Section 5) Master files are sometimes called "zone
../rfc8499.txt: Slave server: See "Secondary server".
../rfc8499.txt: Master server: See "Primary server".
../rfc8499.txt: Section 2.1) [RFC2136] defines "primary master" as "Master server
../rfc8499.txt: Master file 14
../rfc8499.txt: Master server 19
../rfc8499.txt: Slave server 19
../rfc8501.txt: Primary Master Server for the longest match required. Once found,
../rfc8505.txt: Donaldson, "Transmission of IPv6 over Master-Slave/Token-
../rfc8505.txt: Master-Slave/Token-Passing [RFC8163], Digital Enhanced Cordless
../rfc8548.txt: Master keys are then computed from s[i] and sn[i] as described in
../rfc8578.txt: The Global Positioning System (GPS) Master Clock can send 1PPS or
../rfc8607.txt: Master instance: The value "M" (case insensitive) refers to the
../rfc8613.txt: 12.3. Master Secret . . . . . . . . . . . . . . . . .. . . . . 52
../rfc8613.txt: C.1. Test Vector 1: Key Derivation with Master Salt .. . . . . 75
../rfc8613.txt: C.2. Test Vector 2: Key Derivation without Master Salt . . . . 77
../rfc8613.txt: The terms Common Context, Sender Context, Recipient Context, Master
../rfc8613.txt: Secret, Master Salt, Sender ID, Sender Key, Recipient ID, Recipient
../rfc8613.txt: o Master Secret. Variable length, random byte string (see
../rfc8613.txt: o Master Salt. Optional variable-length byte string containing the
../rfc8613.txt: o Common IV. Byte string derived from the Master Secret, Master
../rfc8613.txt: may free up memory by not storing the Master Secret and Master Salt
../rfc8613.txt: o Master Secret
../rfc8613.txt: o Master Salt
../rfc8613.txt: o salt is the Master Salt as defined above
../rfc8613.txt: o IKM is the Master Secret as defined above
../rfc8613.txt: PRK = HMAC-SHA-256(Master Salt, Master Secret)
../rfc8613.txt: To ensure unique Sender Keys, the quartet (Master Secret, Master
../rfc8613.txt: contexts using the same Master Secret and Master Salt. This means
../rfc8613.txt: using the same Master Secret, Master Salt, and ID Context; such a
../rfc8613.txt: 2. The endpoints can reuse an existing shared Master Secret and
../rfc8613.txt: secrecy resulting in a fresh Master Secret, from which an
../rfc8613.txt: on a common Master Secret and unique Sender IDs. The necessary input
../rfc8613.txt: with a fixed Master Secret are given in Appendix B.
../rfc8613.txt:12.3. Master Secret
../rfc8613.txt: focus on the Master Secret. In this specification, HKDF denotes the
../rfc8613.txt: [RFC5869] and the Master Secret is used as Input Keying Material
../rfc8613.txt: Therefore, the main requirement for the OSCORE Master Secret, in
../rfc8613.txt: the necessary properties for the Master Secret are fulfilled. For
../rfc8613.txt: [OSCORE-PROFILE], the Master Secret can be generated offline using a
../rfc8613.txt: keys (see Section 3.1 of [RFC8152]), and by using a Master Salt in
../rfc8613.txt: the key derivation (see [MF00] for an overview). The Master Secret,
../rfc8613.txt: the parameters may be public. The Master Secret must have a good
../rfc8613.txt: random Master Key is sufficient for encrypting all data exchanged
../rfc8613.txt: derived once from the Master Secret. In the second example, security
../rfc8613.txt: multiple security contexts to be derived from one Master Secret. The
../rfc8613.txt: preestablished between client and server, in particular Master
../rfc8613.txt: Secret, Master Salt, and Sender/Recipient ID (see Section 3.2), to
../rfc8613.txt: of input parameters (including Master Secret, Sender and Recipient
../rfc8613.txt: (protected with a key derived from the random value R3 and the Master
../rfc8613.txt: the Master Secret) was created by the client in response to response
../rfc8613.txt: access to the Master Secret will fail to verify.
../rfc8613.txt:C.1. Test Vector 1: Key Derivation with Master Salt
../rfc8613.txt: In this test vector, a Master Salt of 8 bytes is used. The default
../rfc8613.txt: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
../rfc8613.txt: o Master Salt: 0x9e7ca92223786340 (8 bytes)
../rfc8613.txt: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
../rfc8613.txt: o Master Salt: 0x9e7ca92223786340 (8 bytes)
../rfc8613.txt:C.2. Test Vector 2: Key Derivation without Master Salt
../rfc8613.txt: HKDF, and Master Salt.
../rfc8613.txt: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
../rfc8613.txt: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
../rfc8613.txt: In this test vector, a Master Salt of 8 bytes and an ID Context of 8
../rfc8613.txt: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
../rfc8613.txt: o Master Salt: 0x9e7ca92223786340 (8 bytes)
../rfc8613.txt: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
../rfc8613.txt: o Master Salt: 0x9e7ca92223786340 (8 bytes)
../rfc8613.txt: OSCORE depends on a preestablished random Master Secret
../rfc8621.txt: <div>Master of Email</div>",
../rfc8645.txt: 6.2. Constructions that Do Not Require a Master Key .. . . . . 23
../rfc8645.txt: 6.3. Constructions that Require a Master Key . . . . .. . . . . 29
../rfc8645.txt: 6.3.1. ACPKM-Master Key Derivation from the Master Key . . . 29
../rfc8645.txt: 6.3.2. CTR-ACPKM-Master Encryption Mode . . . . . .. . . . . 31
../rfc8645.txt: 6.3.3. GCM-ACPKM-Master Authenticated Encryption Mode . . . 33
../rfc8645.txt: 6.3.4. CBC-ACPKM-Master Encryption Mode . . . . . .. . . . . 37
../rfc8645.txt: 6.3.5. CFB-ACPKM-Master Encryption Mode . . . . . .. . . . . 39
../rfc8645.txt: 6.3.6. OMAC-ACPKM-Master Authentication Mode . . . .. . . . . 40
../rfc8645.txt: Require a Master Key . . . . . . . . . . . .. . . . . 52
../rfc8645.txt: A.2.2. Internal Re-keying Mechanisms with a Master Key . . . 56
../rfc8645.txt: Master that do not use a master key and use a master key,
../rfc8645.txt: form. A specific approach (ACPKM and ACPKM-Master re-keying
../rfc8645.txt:6.2. Constructions that Do Not Require a Master Key
../rfc8645.txt: Figure 9: Internal Re-keying without a Master Key
../rfc8645.txt:6.3. Constructions that Require a Master Key
../rfc8645.txt: Master re-keying mechanism, which use the initial key K as a master
../rfc8645.txt:6.3.1. ACPKM-Master Key Derivation from the Master Key
../rfc8645.txt: which is called the ACPKM-Master re-keying mechanism. This mechanism
../rfc8645.txt: operation that use the ACPKM-Master re-keying mechanism are the
../rfc8645.txt: Master key frequency T*,
../rfc8645.txt: Figure 10: Internal Re-keying with a Master Key
../rfc8645.txt: some mode of operation that uses ACPKM-Master key transformation with
../rfc8645.txt: calculated with the ACPKM-Master algorithm as follows:
../rfc8645.txt: K[1] | ... | K[l] = ACPKM-Master(T*, K, d, l) = CTR-ACPKM-Encrypt
../rfc8645.txt:6.3.2. CTR-ACPKM-Master Encryption Mode
../rfc8645.txt: This section defines a CTR-ACPKM-Master encryption mode that uses the
../rfc8645.txt: ACPKM-Master internal re-keying mechanism for the periodical key
../rfc8645.txt: The CTR-ACPKM-Master encryption mode can be considered as the base
../rfc8645.txt: encryption mode CTR (see [MODES]) extended by the ACPKM-Master
../rfc8645.txt: The CTR-ACPKM-Master encryption mode can be used with the following
../rfc8645.txt: The CTR-ACPKM-Master mode encryption and decryption procedures are
../rfc8645.txt: | CTR-ACPKM-Master-Encrypt(N, K, T*, ICN, P) |
../rfc8645.txt: | 4. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) |
../rfc8645.txt: | CTR-ACPKM-Master-Decrypt(N, K, T*, ICN, C) |
../rfc8645.txt: | 1. P = CTR-ACPKM-Master-Encrypt(N, K, T*, ICN, C) |
../rfc8645.txt:6.3.3. GCM-ACPKM-Master Authenticated Encryption Mode
../rfc8645.txt: This section defines a GCM-ACPKM-Master authenticated encryption mode
../rfc8645.txt: that uses the ACPKM-Master internal re-keying mechanism for the
../rfc8645.txt: The GCM-ACPKM-Master authenticated encryption mode can be considered
../rfc8645.txt: the ACPKM-Master re-keying mechanism.
../rfc8645.txt: The GCM-ACPKM-Master authenticated encryption mode can be used with
../rfc8645.txt: The GCM-ACPKM-Master mode encryption and decryption procedures are
../rfc8645.txt: | 5. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) |
../rfc8645.txt: | GCM-ACPKM-Master-Encrypt(N, K, T*, ICN, P, A) |
../rfc8645.txt: | 1. K^1 = ACPKM-Master(T*, K, k, 1) |
../rfc8645.txt: | GCM-ACPKM-Master-Decrypt(N, K, T*, ICN, A, C, T) |
../rfc8645.txt: | 1. K^1 = ACPKM-Master(T*, K, k, 1) |
../rfc8645.txt:6.3.4. CBC-ACPKM-Master Encryption Mode
../rfc8645.txt: This section defines a CBC-ACPKM-Master encryption mode that uses the
../rfc8645.txt: ACPKM-Master internal re-keying mechanism for the periodical key
../rfc8645.txt: The CBC-ACPKM-Master encryption mode can be considered as the base
../rfc8645.txt: encryption mode CBC (see [MODES]) extended by the ACPKM-Master
../rfc8645.txt: The CBC-ACPKM-Master encryption mode can be used with the following
../rfc8645.txt: In the specification of the CBC-ACPKM-Master mode, the plaintext and
../rfc8645.txt: The CBC-ACPKM-Master mode encryption and decryption procedures are
../rfc8645.txt: | CBC-ACPKM-Master-Encrypt(N, K, T*, IV, P) |
../rfc8645.txt: | 2. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) |
../rfc8645.txt: | CBC-ACPKM-Master-Decrypt(N, K, T*, IV, C) |
../rfc8645.txt: | 2. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) |
../rfc8645.txt:6.3.5. CFB-ACPKM-Master Encryption Mode
../rfc8645.txt: This section defines a CFB-ACPKM-Master encryption mode that uses the
../rfc8645.txt: ACPKM-Master internal re-keying mechanism for the periodical key
../rfc8645.txt: The CFB-ACPKM-Master encryption mode can be considered as the base
../rfc8645.txt: encryption mode CFB (see [MODES]) extended by the ACPKM-Master
../rfc8645.txt: The CFB-ACPKM-Master encryption mode can be used with the following
../rfc8645.txt: The CFB-ACPKM-Master mode encryption and decryption procedures are
../rfc8645.txt: | CFB-ACPKM-Master-Encrypt(N, K, T*, IV, P) |
../rfc8645.txt: | 2. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) |
../rfc8645.txt: | CFB-ACPKM-Master-Decrypt(N, K, T*, IV, C) |
../rfc8645.txt: | 2. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) |
../rfc8645.txt:6.3.6. OMAC-ACPKM-Master Authentication Mode
../rfc8645.txt: This section defines an OMAC-ACPKM-Master message authentication code
../rfc8645.txt: calculation mode that uses the ACPKM-Master internal re-keying
../rfc8645.txt: The OMAC-ACPKM-Master mode can be considered as the base message
../rfc8645.txt: CMAC (see [RFC4493]), extended by the ACPKM-Master re-keying
../rfc8645.txt: The OMAC-ACPKM-Master message authentication code calculation mode
../rfc8645.txt: The OMAC-ACPKM-Master message authentication code calculation mode is
../rfc8645.txt: | OMAC-ACPKM-Master(K, N, T*, M) |
../rfc8645.txt: = ACPKM-Master(T*, K, (k + n), l) |
../rfc8645.txt:A.2.1. Internal Re-keying Mechanisms that Do Not Require a Master Key
../rfc8645.txt:A.2.2. Internal Re-keying Mechanisms with a Master Key
../rfc8645.txt: CTR-ACPKM-Master mode with AES-256
../rfc8645.txt: c for CTR-ACPKM-Master mode = 64
../rfc8645.txt: GCM-ACPKM-Master mode with AES-256
../rfc8645.txt: c for the GCM-ACPKM-Master mode = 32
../rfc8645.txt: CBC-ACPKM-Master mode with AES-256
../rfc8645.txt: CFB-ACPKM-Master mode with AES-256
../rfc8645.txt: OMAC-ACPKM-Master mode with AES-256
../rfc8656.xml: <t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</t>
../rfc8685.xml: <t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</t>
../rfc8751.xml: <t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</t>
../rfc8773.txt: curves. As a result, the Early Secret, Handshake Secret, and Master
../rfc8773.xml: Secret, and Master Secret values all depend upon the value of the
../rfc8782.xml: <t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</t>
../rfc8783.xml: <t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</t>
../rfc8794.txt: 7.7. Master Element
../rfc8794.txt: "Master Element": The "Master Element" contains zero, one, or many
../rfc8794.txt: the "EBML Elements" immediately contained within a "Master
../rfc8794.txt: "Parent Element": A relative term to describe the "Master Element"
../rfc8794.txt: to the "Master Element" in which that "EBML Element" is directly
../rfc8794.txt: Elements" contained within a "Master Element", including any of
../rfc8794.txt: within a "Master Element" for later use.
../rfc8794.txt: is referred to as an Unknown-Sized Element. Only a Master Element is
../rfc8794.txt:7.7. Master Element
../rfc8794.txt: A Master Element MUST declare a length in octets from zero to VINTMAX
../rfc8794.txt: The Master Element contains zero or more other elements. EBML
../rfc8794.txt: Elements contained within a Master Element MUST have the
../rfc8794.txt: Master Element Element Path (see Section 11.1.6.2). Element Data
../rfc8794.txt: stored within Master Elements SHOULD only consist of EBML Elements
../rfc8794.txt: Master Elements for that version of the EBML Document Type. Any data
../rfc8794.txt: contained within a Master Element that is not part of a Child Element
../rfc8794.txt: The EBML Header MUST contain a single Master Element with an Element
../rfc8794.txt: the Master Element may have any number of additional EBML Elements
../rfc8794.txt: Elements that are Master Elements MUST NOT declare a default value.
../rfc8794.txt: of Element Data Size set to 1). EBML Elements that are not Master
../rfc8794.txt: the same Element ID, and so on. EBML Elements that are not Master
../rfc8794.txt: type: Master Element
../rfc8794.txt: type: Master Element
../rfc8794.txt: Top-Level Elements of an EBML Document that are Master Elements
../rfc8794.txt: If a Master Element contains a CRC-32 Element that doesn't validate,
../rfc8794.txt: fragment, a Master Element called CONTACT contains two Child
../rfc8794.txt: If a Master Element contains more occurrences of a Child Master
../rfc8794.txt: If a Master Element contains more occurrences of a Child Element than
../rfc8794.txt: If the Element to be changed is a Descendant Element of any Master
../rfc8794.txt: * Missing EBML Elements that are mandatory in a Master Element and
../rfc8794.txt: that Master Element level.
../rfc8794.txt: * The CRC-32 Element (see Section 11.3.1) of a Master Element
../rfc8794.txt: doesn't match the rest of the content of that Master Element.
../rfc8794.txt: * Data contained within a Master Element that is not itself part of
../rfc8794.xml: <t pn="section-toc.1-1.7.2.7.1"><xref derivedContent="7.7" format="counter" sectionFormat="of" target="section-7.7"/>.Â Â <xref derivedContent="" format="title" sectionFormat="of" target="name-master-element">Master Element</xref></t>
../rfc8794.xml: <dt pn="section-2-3.39"><tt>Master Element</tt>:</dt>
../rfc8794.xml: <dd pn="section-2-3.40">The <tt>Master Element</tt> contains zero, one, or many other <tt>EBML Elements</tt>.</dd>
../rfc8794.xml:immediately contained within a <tt>Master Element</tt>.</dd>
../rfc8794.xml: <dd pn="section-2-3.44">A relative term to describe the <tt>Master Element</tt> that contains a
../rfc8794.xml:<tt>Root Level</tt>, the <tt>Parent Element</tt> refers to the <tt>Master Element</tt>
../rfc8794.xml:<tt>Master Element</tt>, including any of the <tt>Child Elements</tt> of its
../rfc8794.xml:reserve space within a <tt>Master Element</tt> for later use.</dd>
../rfc8794.xml:Element. Only a Master Element is allowed to be of unknown size, and it can
../rfc8794.xml: <name slugifiedName="name-master-element">Master Element</name>
../rfc8794.xml: <t pn="section-7.7-1">A Master Element <bcp14>MUST</bcp14> declare a length in octets from zero to VINTMAX or be of unknown length. See <xref target="element-data-size" format="default" sectionFormat="of" derivedContent="Section 6"/> for rules that apply to elements of unknown length.</t>
../rfc8794.xml: <t pn="section-7.7-2">The Master Element contains zero or more other elements. EBML Elements contained within a Master Element <bcp14>MUST</bcp14> have the EBMLParentPath of their Element Path equal to the EBMLFullPath of the Master Element Element Path (see <xref target="path" format="default" sectionFormat="of" derivedContent="Section 11.1.6.2"/>). Element Data stored within Master Elements <bcp14>SHOULD</bcp14> only consist of EBML Elements and <bcp14>SHOULD NOT</bcp14> contain any data that is not part of an EBML Element. The EBML Schema identifies what Element IDs are valid within the Master Elements for that version of the EBML Document Type. Any data contained within a Master Element that is not part of a Child Element <bcp14>MUST</bcp14> be ignored.</t>
../rfc8794.xml: <t pn="section-8.1-3">The EBML Header <bcp14>MUST</bcp14> contain a single Master Element with an
../rfc8794.xml:<xref target="ebml-element" format="default" sectionFormat="of" derivedContent="Section 11.2.1"/>); the Master Element may have any number of
../rfc8794.xml:EBML Elements that are Master Elements <bcp14>MUST NOT</bcp14> declare a default value.
../rfc8794.xml:to 1). EBML Elements that are not Master Elements <bcp14>MUST NOT</bcp14> set
../rfc8794.xml:Elements that are not Master Elements <bcp14>MUST NOT</bcp14> set recursive to
../rfc8794.xml: <dd pn="section-11.2.1-1.12">Master Element</dd>
../rfc8794.xml: <dd pn="section-11.2.9-1.10">Master Element</dd>
../rfc8794.xml:are Master Elements <bcp14>SHOULD</bcp14> include a CRC-32 Element as a Child
../rfc8794.xml: <t pn="section-12-2">If a Master Element contains a CRC-32 Element that doesn't validate, then
../rfc8794.xml:fragment, a Master Element called CONTACT contains two Child Elements, NAME
../rfc8794.xml: <t pn="section-12-5">If a Master Element contains more occurrences of a Child Master Element
../rfc8794.xml: <t pn="section-12-6">If a Master Element contains more occurrences of a Child Element than
../rfc8794.xml: <t pn="section-14.2-1">If the Element to be changed is a Descendant Element of any Master Element
../rfc8794.xml: <t pn="section-16-8.3.1">Missing EBML Elements that are mandatory in a Master Element and have no declared default value, making the semantic invalid at that Master Element level.</t>
../rfc8794.xml: <t pn="section-16-8.6.1">The CRC-32 Element (see <xref target="crc-32-element" format="default" sectionFormat="of" derivedContent="Section 11.3.1"/>) of a Master Element doesn't match the rest of the content of that Master Element.</t>
../rfc8794.xml: <t pn="section-16-10.3.1">Data contained within a Master Element that is not itself part of a Child Element, which can trigger incorrect parsing behavior in EBML Readers.</t>
../rfc8803.xml: <t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</t>
../rfc8806.txt: 5. In the "Master DNS Servers" dialog box, enter
../rfc8806.xml: <li pn="section-b.6-4.5" derivedCounter="5.">In the "Master DNS Servers" dialog box, enter
../rfc882.txt: master files are updated by local system administrators. Master
../rfc882.txt: Master files of data
../rfc883.txt: | Master |-------------->| Server | | |Resolver|
../rfc883.txt: | Master |-------------->| Server | | |Resolver|
../rfc883.txt: | Master |-------------->| Server | | |Resolver|
../rfc883.txt: Master files and zone copies from remote servers may include RRs
../rfc883.txt: Master files are kept in text form for ease of editing by system
../rfc973.txt: Master file format
../std/std13.txt:files are updated by local system administrators. Master files are text
../std/std13.txt: - Master files of data.
../std/std13.txt: 5.3. Master file example 36
../std/std13.txt: | Master |-------------->| Server | | |Resolver|
../std/std13.txt: | Master |-------------->| Server | | |Resolver|
../std/std13.txt: | Master |-------------->| Server | | |Resolver|
../std/std13.txt:Master files are text files that contain RRs in text form. Since the
../std/std13.txt:5.3. Master file example
../std/std54.txt: Master/Slave
../std/std54.txt:	 The	Master/Slave relationship has been negotiated, and DD
../std/std54.txt:		the router is now Slave. Set the master/slave bit to
../std/std54.txt:		Master.
../std/std54.txt:	Master
../std/std54.txt:	Slave
../std/std54.txt:	Master
../std/std54.txt:	Slave
../std/std54.txt:	 ExStart	 D-D (Seq=x,I,M,Master)
../std/std54.txt:			 D-D (Seq=y,I,M,Master)	 ExStart
../std/std54.txt:	 Exchange	 D-D (Seq=y,M,Slave)
../std/std54.txt:			 D-D (Seq=y+1,M,Master)	 Exchange
../std/std54.txt:			 D-D (Seq=y+1,M,Slave)
../std/std54.txt:			 D-D (Seq=y+n, Master)
../std/std54.txt:			 D-D (Seq=y+n, Slave)
../std/std54.txt:	The Master/Slave bit. When set	to 1, it indicates that	the
../words.txt:Master
../words.txt:Slave
../words.txt:Blacklist
../words.txt:Whitelist
draft-alavarez-hamelin-tictoc-sic-05.txt: 3.2.4 Rogue Master Attack: Prevented by secure key distribution.
draft-birkholz-rats-tuda-03.txt: Master Thesis (Diplomarbeit), Technische Universitaet
draft-bookham-rtgwg-nfix-arch-01.txt: Master/standby election, state synchronisation, and failure detection
draft-cooley-cnsa-dtls-tls-profile-04.txt: Session Hash and Extended Master Secret Extension",
draft-dcn-bmwg-containerized-infra-04.txt: | for Master | CPU E5-2690 | and Network Allocation |
draft-dcn-bmwg-containerized-infra-04.txt: | |- MEM 128G |- Kubernetes Master |
draft-dcn-bmwg-containerized-infra-04.txt: | | | Containerized Infrastructure Master Node |
draft-friel-tls-eap-dpp-01.txt: 0 -> HKDF-Extract = Master Secret
draft-hallambaker-mesh-architecture-14.txt: Alice's ProfileMaster contains a Master Signature Key used to sign
draft-hallambaker-mesh-architecture-14.txt: Profile Master and delete it from her device(s), thus ensuring that
draft-hallambaker-mesh-architecture-14.txt: her personal Mesh. Recovery of the Master Signature Key and the
draft-hallambaker-mesh-architecture-14.txt: associated Master Encryption Escrow keys (not shown) allows Alice to
draft-hallambaker-mesh-architecture-14.txt: associated with the Master Profile.
draft-hallambaker-mesh-architecture-14.txt: Master Profile. Such devices are referred to as Administration
draft-hallambaker-mesh-architecture-14.txt: Loss of a Master Signature Key potentially means the loss of the
draft-hallambaker-mesh-architecture-14.txt: corresponding to their Master Profile Signature and Escrow keys.
draft-hallambaker-mesh-architecture-14.txt: Having recovered the Master Signature Key, the user can now create a
draft-hallambaker-mesh-dare-08.txt: exchange and data encryption operations so that a Master Key (MK)
draft-hallambaker-mesh-dare-08.txt: encryption key (and IV if required) derived from the Master Key by
draft-hallambaker-mesh-dare-08.txt: but it is more appropriately described as a Master Key (figure 2).
draft-hallambaker-mesh-dare-08.txt: A Master Key may be used to encrypt any number of data items. Each
draft-hallambaker-mesh-dare-08.txt: required). This data is derived from the Master Key using the HKDF
draft-hallambaker-mesh-dare-08.txt: Each encrypted DARE Envelope specifies a unique Master Salt value of
draft-hallambaker-mesh-dare-08.txt: Erasure of the Master Salt value MAY be used to effectively render
draft-hallambaker-mesh-dare-08.txt: Master Key (MK) The master secret from which keys are derived for
draft-hallambaker-mesh-dare-08.txt: exchange information and hence the same Master Key.
draft-hallambaker-mesh-dare-08.txt: exchange is the DARE Master Key rather than the Content Encryption
draft-hallambaker-mesh-dare-08.txt: providing a means of decrypting the Master Key using a different
draft-hallambaker-mesh-dare-08.txt: A Master Salt is a sequence of 16 or more octets that is specified in
draft-hallambaker-mesh-dare-08.txt: The Master Salt is used to derive salt values for the envelope
draft-hallambaker-mesh-dare-08.txt: Payload Salt = Master Salt
draft-hallambaker-mesh-dare-08.txt: EDS Salt = Concatenate (Payload Salt Prefix, Master Salt)
draft-hallambaker-mesh-dare-08.txt: * Transmit the Master Key in the manner of a Kerberos ticket.
draft-hallambaker-mesh-dare-08.txt: * Identify the Master Key under which the Enhanced Data Sequence was
draft-hallambaker-mesh-dare-08.txt: Encryption and/or authentication keys are derived from the Master Key
draft-hallambaker-mesh-dare-08.txt: 0. The Master Key and salt value are used to extract the PRK
draft-hallambaker-mesh-dare-08.txt: [RFC3394] is used to wrap the Master Exchange Key. AES 256 is used.
draft-hallambaker-mesh-dare-08.txt: KeyIdentifier: String (Optional) Master key identifier.
draft-hallambaker-mesh-dare-08.txt: Master Key. The interpretation of these fields is application
draft-hallambaker-mesh-dare-08.txt: Data Sequence under the message Master Key.
draft-hallambaker-mesh-protocol-06.txt: containers between the service (Master) and the connected devices
draft-hallambaker-mesh-protocol-06.txt: Exchange [draft-hallambaker-mesh-security] to establish the Master
draft-hallambaker-mesh-security-05.txt: MeshProfileUDF: String (Optional) Master profile of the account
draft-hallambaker-mesh-security-05.txt: Master profile keys should be escrowed
draft-hallambaker-mesh-trust-06.txt: 3.1. Master Profile . . . . . .. . . . . . . . . . . . . . . . 22
draft-hallambaker-mesh-trust-06.txt:3.1. Master Profile
draft-hallambaker-mesh-trust-06.txt: designed to permit (but not require) life long use. A Master profile
draft-hohendorf-secure-sctp-29.txt: 9.5. Generation of the Master secret key . . . . . . . . . . . 30
draft-hohendorf-secure-sctp-29.txt: o Master secret key: S-SCTP uses two kinds of secret keys. One is
draft-hohendorf-secure-sctp-29.txt: | Master secret key reference # | Random number length |
draft-hohendorf-secure-sctp-29.txt: Master secret key reference number: 16 bits unsigned integer
draft-hohendorf-secure-sctp-29.txt: | Master secret key reference # | Reserved=0 |
draft-hohendorf-secure-sctp-29.txt: Master secret key reference number: 16 bits unsigned integer
draft-hohendorf-secure-sctp-29.txt:9.5. Generation of the Master secret key
draft-hohendorf-secure-sctp-29.txt: Master secret key reference:
draft-ietf-6lo-use-cases-09.txt: Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token
draft-ietf-6lo-use-cases-09.txt: Master-Slave/Token-Passing (MS/TP) is a Medium Access Control (MAC)
draft-ietf-6lo-use-cases-09.txt: Donaldson, "Transmission of IPv6 over Master-Slave/Token-
draft-ietf-6tisch-minimal-security-15.txt: o the Master Secret MUST be the PSK.
draft-ietf-6tisch-minimal-security-15.txt: o the Master Salt MUST be the empty byte string.
draft-ietf-6tisch-minimal-security-15.txt: PSK is used to set the OSCORE Master Secret during security context
draft-ietf-ace-coap-est-18.txt: binding is in use. Implementers should use the Extended Master
draft-ietf-ace-coap-est-18.txt: Session Hash and Extended Master Secret Extension",
draft-ietf-ace-key-groupcomm-oscore-08.txt: o a new value for the Master Secret parameter of the OSCORE Common
draft-ietf-ace-key-groupcomm-oscore-08.txt: Master Salt parameter of the OSCORE Common Security Context of that
draft-ietf-ace-key-groupcomm-oscore-08.txt: Master Secret value.
draft-ietf-ace-key-groupcomm-oscore-08.txt: Master Salt.
draft-ietf-ace-key-groupcomm-oscore-08.txt: OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for
draft-ietf-ace-key-groupcomm-oscore-08.txt: Master Secret value.
draft-ietf-ace-oscore-gm-admin-00.txt: o The OSCORE Master Secret.
draft-ietf-ace-oscore-gm-admin-00.txt: o The OSCORE Master Salt (optionally).
draft-ietf-ace-oscore-profile-11.txt: concatenates the input salt, N1, and N2 to obtain the Master Salt of
draft-ietf-ace-oscore-profile-11.txt: N1 and N2 to obtain the Master Salt of the OSCORE Security Context
draft-ietf-ace-oscore-profile-11.txt: Master Salt, the request to the authz-info endpoint posting the same
draft-ietf-ace-oscore-profile-11.txt: construction, since even though the Master Secret, Sender ID and
draft-ietf-ace-oscore-profile-11.txt: Recipient ID are the same, the Master Salt is different (see
draft-ietf-ace-oscore-profile-11.txt: | ms | 1 | bstr | | OSCORE Master |
draft-ietf-ace-oscore-profile-11.txt: | salt | 6 | bstr | | OSCORE Master |
draft-ietf-ace-oscore-profile-11.txt: ms: This parameter identifies the OSCORE Master Secret value, which
draft-ietf-ace-oscore-profile-11.txt: salt: This parameter identifies the OSCORE Master Salt value, which
draft-ietf-ace-oscore-profile-11.txt: payload of the response. Then, the client MUST set the Master Salt
draft-ietf-ace-oscore-profile-11.txt: concatenation of salt, N1, and N2, in this order: Master Salt =
draft-ietf-ace-oscore-profile-11.txt: two nonces encoded as CBOR bstr. The client MUST set the Master
draft-ietf-ace-oscore-profile-11.txt: After sending the 2.01 (Created) response, the RS MUST set the Master
draft-ietf-ace-oscore-profile-11.txt: to the concatenation of salt, N1, and N2, in this order: Master Salt
draft-ietf-ace-oscore-profile-11.txt: the two nonces encoded as CBOR bstr. The RS MUST set the Master
draft-ietf-cellar-codec-04.txt: Audio and DTS-HD Master Audio. The private data is void.
draft-ietf-core-groupcomm-bis-01.txt: OSCORE Master Secret used in such derivation is securely generated
draft-ietf-core-oscore-groupcomm-09.txt: 10.9. Master Secret . . . .. . . . . . . . . . . . . . . . . . 41
draft-ietf-core-oscore-groupcomm-09.txt: as "Security Context" and "Master Secret", defined in [RFC8613].
draft-ietf-core-oscore-groupcomm-09.txt: Master Secret, Master Salt and Group Identifier (see Section 3.3 of
draft-ietf-core-oscore-groupcomm-09.txt: the Gid, Master Secret and Master Salt unchanged. In this case the
draft-ietf-core-oscore-groupcomm-09.txt: Contexts (see Section 2.2). The Master Salt used for the re-
draft-ietf-core-oscore-groupcomm-09.txt: derivations is the updated Master Salt parameter if provided by the
draft-ietf-core-oscore-groupcomm-09.txt: The distribution of a new Gid and Master Secret may result in
draft-ietf-core-oscore-groupcomm-09.txt: process messages received right after a new Gid and Master Secret
draft-ietf-core-oscore-groupcomm-09.txt: Identifier (Gid) for that group and a new value for the Master Secret
draft-ietf-core-oscore-groupcomm-09.txt: Gid and Master Secret, the Group Manager MAY distribute also a new
draft-ietf-core-oscore-groupcomm-09.txt: value for the Master Salt parameter, and SHOULD preserve the current
draft-ietf-core-oscore-groupcomm-09.txt: ('kid') with the same Gid, Master Secret and Master Salt. Even if
draft-ietf-core-oscore-groupcomm-09.txt: Gid and Master Secret are renewed as described in this section, the
draft-ietf-core-oscore-groupcomm-09.txt: value for the Gid and for the Master Secret parameter of the group's
draft-ietf-core-oscore-groupcomm-09.txt: Manager supports the distribution of the new Gid and Master Secret
draft-ietf-core-oscore-groupcomm-09.txt: long as the Master Secret is different for different groups and this
draft-ietf-core-oscore-groupcomm-09.txt: intended OSCORE group, hence to the triplet (Master Secret, Master
draft-ietf-core-oscore-groupcomm-09.txt: quartet (Master Secret, Master Salt, ID Context, Sender ID).
draft-ietf-core-oscore-groupcomm-09.txt:10.9. Master Secret
draft-ietf-core-oscore-groupcomm-09.txt: With particular reference to the OSCORE Master Secret, it has to be
draft-ietf-core-oscore-groupcomm-09.txt: Group Manager responsible for that group. Also, the Master Secret
draft-ietf-core-oscore-groupcomm-09.txt: generating and distributing a new Master Secret. Randomness
draft-ietf-detnet-security-10.txt: new Best Master Clock selection process. Thus attacks on time sync
draft-ietf-emu-aka-pfs-04.txt: attribute is also set to 1, the Master Key (MK) is derived as follows
draft-ietf-emu-aka-pfs-04.txt: the Master Session Key, 512 bits, and EMSK is the Extended Master
draft-ietf-emu-eap-tls13-10.txt: without having to extract the Master Secret, ClientHello.random, and
draft-ietf-emu-rfc5448bis-07.txt: bits), K_re (re-authentication key, 256 bits), MSK (Master Session
draft-ietf-emu-rfc5448bis-07.txt: Key, 512 bits), and EMSK (Extended Master Session Key, 512 bits).
draft-ietf-emu-rfc5448bis-07.txt: algorithm, can compute the keys CK' and IK' and, hence, the Master
draft-ietf-emu-rfc5448bis-07.txt: change how the Master Key (MK) is calculated or any other aspect of
draft-ietf-hip-dex-21.txt: [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but
draft-ietf-hip-dex-21.txt: has two forms of SAs, a Master Key SA for the actual HIP traffic,
draft-ietf-hip-dex-21.txt: the Master Key Security Association (SA) generation. This Master Key
draft-ietf-hip-dex-21.txt: the Master Key SA by including a list of Diffie-Hellman Group IDs
draft-ietf-hip-dex-21.txt: based on the Master Key SA (indicated by ENC and DH). Note that x
draft-ietf-hip-dex-21.txt: Diffie-Hellman derived key, or Master Key, and one for the session
draft-ietf-hip-dex-21.txt:4.1.3.1. Master Key SA
draft-ietf-hip-dex-21.txt: The Master Key SA is used to authenticate HIP packets and to encrypt
draft-ietf-hip-dex-21.txt: The Master Key SA contains the following elements:
draft-ietf-hip-dex-21.txt: | | (suggested | | for Master Key |
draft-ietf-hip-dex-21.txt: Master Key SA.
draft-ietf-hip-dex-21.txt: Nonce Master Key
draft-ietf-hip-dex-21.txt: in the Master key creation process (see Section 6.3). This random
draft-ietf-hip-dex-21.txt: encrypted with the Master Key SA using the HIP_CIPHER encryption
draft-ietf-hip-dex-21.txt: for the Master Key generation as shown in Section 6.3. This is
draft-ietf-hip-dex-21.txt: encrypted with the Master Key SA using the HIP_CIPHER encryption
draft-ietf-hip-dex-21.txt: for the Master Key generation as shown in Section 6.3. The Responder
draft-ietf-hip-dex-21.txt: The HIP DEX KEYMAT process is used to derive the keys for the Master
draft-ietf-hip-dex-21.txt: Key SA as well as for the Pair-wise Key SA. The keys for the Master
draft-ietf-hip-dex-21.txt: The key derivation for the Master Key SA employs always both the
draft-ietf-hip-dex-21.txt: random I_NONCE value for the Master Key SA
draft-ietf-hip-dex-21.txt: The initial keys for the Master Key SA are drawn sequentially in the
draft-ietf-hip-dex-21.txt: keying material is used to derive the keys of the Master Key SA
draft-ietf-hip-dex-21.txt: o The strength of the keys for both the Master and Pair-wise Key SAs
draft-ietf-hip-dex-21.txt: the authenticity of this packet as it did not yet set up the Master
draft-ietf-hip-rfc4423-bis-20.txt: Xin, G., "Host Identity Protocol Version 2.5", Master's
draft-ietf-hip-rfc4423-bis-20.txt: o Master Keys in 802 protocols are commonly pair-based with group
draft-ietf-homenet-front-end-naming-delegation-11.txt: Infrastructure via a Distribution Master (DM).
draft-ietf-homenet-front-end-naming-delegation-11.txt: 3.2. Distribution Master Communication Channels . . . . . . . 10
draft-ietf-homenet-front-end-naming-delegation-11.txt: Distribution Master (DM) . . . . . . . . . . . . . . . . . . 11
draft-ietf-homenet-front-end-naming-delegation-11.txt: Authority (HNA) and Distribution Master (DM) . . . . . . 15
draft-ietf-homenet-front-end-naming-delegation-11.txt: 10.2. Distribution Master . . . . . . . . . . . . . . . . . . 22
draft-ietf-homenet-front-end-naming-delegation-11.txt: Infrastructure via a Distribution Master (DM). The Outsourcing
draft-ietf-homenet-front-end-naming-delegation-11.txt: primary, and the Distribution Master a secondary.
draft-ietf-homenet-front-end-naming-delegation-11.txt: Internet. It is mainly composed of a Distribution Master and
draft-ietf-homenet-front-end-naming-delegation-11.txt: o Distribution Master (DM): is the (set of) server(s) to which the
draft-ietf-homenet-front-end-naming-delegation-11.txt: o Reverse Distribution Master: equivalent to Distribution Master
draft-ietf-homenet-front-end-naming-delegation-11.txt: | HNA |<-------------->| Distribution Master | |
draft-ietf-homenet-front-end-naming-delegation-11.txt:3.2. Distribution Master Communication Channels
draft-ietf-homenet-front-end-naming-delegation-11.txt: update the Distribution Master's configuration files. The visible NS
draft-ietf-homenet-front-end-naming-delegation-11.txt: Distribution Master (DM)
draft-ietf-homenet-front-end-naming-delegation-11.txt: include information that it retrieves from the Distribution Master
draft-ietf-homenet-front-end-naming-delegation-11.txt: (HNA) and Distribution Master (DM)
draft-ietf-homenet-front-end-naming-delegation-11.txt:10.2. Distribution Master
draft-ietf-homenet-front-end-naming-delegation-11.txt: Renumbering of the Distribution Master results in it changing its IP
draft-ietf-homenet-front-end-naming-delegation-11.txt: coherent with the IP plane. The TTL of the Distribution Master name
draft-ietf-homenet-front-end-naming-delegation-11.txt: trusted relationship to the Distribution Master for the forward zone.
draft-ietf-homenet-front-end-naming-delegation-11.txt: Distribution Master for reverse zones is dealt with in
draft-ietf-homenet-front-end-naming-delegation-11.txt: Outsourcing Infrastructure and the Hidden Master. As a result,
draft-ietf-homenet-naming-architecture-dhc-options-07.txt: 4.2. Distribution Master Option . . . . . . . . . . . . . . . 5
draft-ietf-homenet-naming-architecture-dhc-options-07.txt: Distribution Master (DM) of the Public Homenet Zone and the Reverse
draft-ietf-homenet-naming-architecture-dhc-options-07.txt: Distribution Master Option (OPTION_DM) and the Reverse
draft-ietf-homenet-naming-architecture-dhc-options-07.txt: Distribution Master Option (OPTION_REVERSE_DM).
draft-ietf-homenet-naming-architecture-dhc-options-07.txt: options, i.e. the Distribution Master Option (OPTION_DM) and the
draft-ietf-homenet-naming-architecture-dhc-options-07.txt: Reverse Distribution Master Option (OPTION_REVERSE_DM).
draft-ietf-homenet-naming-architecture-dhc-options-07.txt:4.2. Distribution Master Option
draft-ietf-i2nsf-nsf-monitoring-data-model-03.txt: o filtering_type: URL filtering type. e.g., Blacklist, Whitelist,
draft-ietf-i2nsf-nsf-monitoring-data-model-03.txt: "URL filtering type, e.g., Blacklist, Whitelist,
draft-ietf-kitten-password-storage-00.txt: Session Hash and Extended Master Secret Extension",
draft-ietf-lake-edhoc-00.txt: o The Master Secret and Master Salt are derived as follows where
draft-ietf-lake-edhoc-00.txt: Master Secret = EDHOC-Exporter( "OSCORE Master Secret", length )
draft-ietf-lake-edhoc-00.txt: Master Salt = EDHOC-Exporter( "OSCORE Master Salt", 8 )
draft-ietf-lake-reqs-04.txt: * A shared secret (OSCORE Master Secret) with Perfect Forward
draft-ietf-lake-reqs-04.txt: - Sender IDs are expected to be unique for a given Master Secret,
draft-ietf-lake-reqs-04.txt: more precisely the quartet (Master Secret, Master Salt, ID
draft-ietf-lwig-curve-representations-11.txt: different curve models in his Master's thesis [Rosener]. For an
draft-ietf-lwig-tcp-constrained-node-networks-09.txt: space, such as Master Slave / Token Passing (TP) [RFC8163],
draft-ietf-lwig-tcp-constrained-node-networks-09.txt: Donaldson, "Transmission of IPv6 over Master-Slave/Token-
draft-ietf-mpls-rmr-12.txt: M : Elected Master (0 = no, 1 = yes)
draft-ietf-mpls-rmr-12.txt: R7 R2 <--- 0. Ring Master
draft-ietf-nfsv4-integrity-measurement-08.txt: o Whole file system checksumming can verify so-called Golden Master
draft-ietf-perc-private-media-framework-12.txt: 6.4. Endpoints fabricate an SRTP Master Key . . . . . . . . . 18
draft-ietf-perc-private-media-framework-12.txt:6.4. Endpoints fabricate an SRTP Master Key
draft-ietf-perc-srtp-ekt-diet-13.txt: EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
draft-ietf-perc-srtp-ekt-diet-13.txt: internal to EKT. This is the concatenation of the SRTP Master Key
draft-ietf-perc-srtp-ekt-diet-13.txt: SRTPMasterKey: On the sender side, the SRTP Master Key associated
draft-ietf-perc-srtp-ekt-diet-13.txt: o The SRTP Master Salt associated with any master key encrypted with
draft-ietf-perc-srtp-ekt-diet-13.txt: o The SRTP Master Salt associated with any master key encrypted with
draft-ietf-perc-srtp-ekt-diet-13.txt: 2. The EKTPlaintext field is computed from the SRTP Master Key,
draft-ietf-perc-srtp-ekt-diet-13.txt: Master Key, and SSRC used in EKT processing MUST be the same as
draft-ietf-perc-srtp-ekt-diet-13.txt: Outbound packets SHOULD continue to use the old SRTP Master Key for
draft-ietf-perc-srtp-ekt-diet-13.txt: contains the EKTKey, EKTCipher, and the SRTP Master Salt.
draft-ietf-perc-srtp-ekt-diet-13.txt: to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP
draft-ietf-perc-srtp-ekt-diet-13.txt: Master Salt that is associated with the EKTKey is also retrieved.
draft-ietf-perc-srtp-ekt-diet-13.txt: 6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous
draft-ietf-perc-srtp-ekt-diet-13.txt: the length of the SRTP Master Key MUST be the same as the
draft-ietf-perc-srtp-ekt-diet-13.txt: * If the length of the SRTP Master Key is less than the master
draft-ietf-perc-srtp-ekt-diet-13.txt: specifies that this length is acceptable, then the SRTP Master
draft-ietf-perc-srtp-ekt-diet-13.txt: || Messages protected using the SRTP Master Key sent in
draft-ietf-perc-srtp-ekt-diet-13.txt: The SRTP Master Salt to be used with any Master Key encrypted with
draft-ietf-perc-srtp-ekt-diet-13.txt: The SPI value to be used to reference this EKTKey and SRTP Master
draft-ietf-taps-minset-11.txt: With TCP, this allows to configure Master Key Tuples (MKTs) to
draft-ietf-taps-minset-11.txt: Implementation over TCP: With TCP, this allows to configure Master
draft-ietf-teas-pcecc-use-cases-05.txt: on big data performs by means of Master-Slave architecture in the
draft-ietf-teas-pcecc-use-cases-05.txt: creation of multicast based communications between Master and Slave
draft-ietf-teas-pcecc-use-cases-05.txt: Communication between Master nodes (JobTracker and NameNode) and
draft-ietf-teas-pcecc-use-cases-05.txt: Master Nodes SHOULD identify and find available Slave nodes according
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: 8. Requirements for Master Clocks . . . . . . . . . . . . . . . 8
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: 9. Requirements for Slave Clocks . . . . . . . . . . . . . . . . 8
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: sources in the network (the Master Clocks).
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: The "Best Master Clock Algorithm" (IEEE 1588-2008 [IEEE1588]
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: determine which node shall be the active sending time source (Master
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: Master Clock Algorithm and a few other ways. PTP has its own
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: o Acceptable Master Table: A PTP Slave Clock may maintain a list of
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: o Alternate Master: A PTP Master Clock, which is not the Best
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: Master, may act as a master with the Alternate Master flag set on
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: o Announce message: Contains the Master Clock properties of a Master
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: Clock. Used to determine the Best Master.
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: o Best Master: A clock with a port in the master state, operating
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: consistently with the Best Master Clock Algorithm.
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: o Best Master Clock Algorithm: A method for determining which state
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: identifying which of several PTP Master capable clocks is the best
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: based on the properties each Master Clock sends in its Announce
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: messages between a Master Clock and Slave Clock.
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: o Grandmaster: the primary Master Clock within a domain of a PTP
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: o Master Clock: a clock with at least one port in the master state.
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: domain. It may serve as a Master Clock, or be a slave clock.
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: o Preferred Master: A device intended to act primarily as the
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: o Rogue Master: A clock with a port in the master state, even though
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: it should not be in the master state according to the Best Master
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: o Slave clock: a clock with at least one port in the slave state,
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: o Slave Only Clock: An Ordinary Clock which cannot become a Master
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: o Unicast Negotiation: A mechanism in PTP for Slave Clocks to
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: from a Master Clock.
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: Clocks may be Slave Only Clocks, or be master capable.
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: true it can cause errors in the transfer of time from the Master to
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: the Slave. It is up to the system integrator to design the network
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: Master Clocks, Transparent Clocks and Boundary Clocks MAY be either
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: one-step clocks or two-step clocks. Slave clocks MUST support both
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: event messages. Master Clocks SHALL respond to multicast Delay
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: Master Clocks SHALL respond to unicast Delay Request PTP event
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: check for faulty Master Clocks. The use of multiple simultaneous
draft-ietf-tictoc-ptp-enterprise-profile-17.txt:8. Requirements for Master Clocks
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: Master Clocks SHALL obey the standard Best Master Clock Algorithm
draft-ietf-tictoc-ptp-enterprise-profile-17.txt:9. Requirements for Slave Clocks
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: Slave clocks MUST be able to operate properly in a network which
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: subsystems. Slave Clocks MUST be able to operate properly in the
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: presence of a Rogue Master. Slaves SHOULD NOT Synchronize to a
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: Master which is not the Best Master in its domain. Slaves will
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: continue to recognize a Best Master for the duration of the Announce
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: Time Out Interval. Slaves MAY use an Acceptable Master Table. If a
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: Master is not an Acceptable Master, then the Slave MUST NOT
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: support both two-step or one-step Master clocks. See IEEE 1588
draft-ietf-tictoc-ptp-enterprise-profile-17.txt: The Alternate Master option is also NOT ALLOWED. Clocks operating in
draft-ietf-tls-exported-authenticator-13.txt: Session Hash and Extended Master Secret Extension",
draft-ietf-tls-hybrid-design-00.txt: 0 -> HKDF-Extract = Master Secret
draft-ietf-tls-hybrid-design-00.txt: 0 -> HKDF-Extract = Master Secret
draft-ietf-tls-hybrid-design-00.txt: 0 -> HKDF-Extract = Master Secret
draft-ietf-tls-hybrid-design-00.txt: 0 -> HKDF-Extract = Master Secret
draft-ietf-tls-hybrid-design-00.txt: 0 -> HKDF-Extract = Master Secret
draft-ietf-tls-hybrid-design-00.txt: next_gen_shared_secret -> HKDF-Extract = Master Secret
draft-ietf-tls-semistatic-dh-01.txt: Finished using the Master Secret. These MACs serve different
draft-irtf-cfrg-pairing-friendly-curves-07.txt: Identities, Private and Master Keys",
draft-jhoyla-tls-extended-key-schedule-01.txt: 3.2. Master Secret Injection . . . . . . . . . . . . . . . . . 3
draft-jhoyla-tls-extended-key-schedule-01.txt:3.2. Master Secret Injection
draft-jhoyla-tls-extended-key-schedule-01.txt: To inject key material into the Master Secret it is recommended to
draft-jhoyla-tls-extended-key-schedule-01.txt: 0 -> HKDF-Extract = Master Secret
draft-jhoyla-tls-extended-key-schedule-01.txt: should isolate the Input material from the rest of the Master Secret.
draft-knodel-terminology-03.txt:3.1. Master-Slave
draft-knodel-terminology-03.txt: Master-slave is an offensive and exclusive metaphor that will and
draft-knodel-terminology-03.txt:3.2. Blacklist-Whitelist
draft-knodel-terminology-03.txt: because light cannot escape them. Blacklist-whitelist is not a
draft-knodel-terminology-03.txt: Grant, Barbara M. "Master--slave dialogues in humanities
draft-knodel-terminology-03.txt: [Eglash] Ron Eglash, ., "Broken Metaphor: The Master-Slave Analogy
draft-knodel-terminology-03.txt: [Github] Kevin Truong, . and VICE, "Github to Remove 'Master/Slave'
draft-kompella-spring-rmr-02.txt: Ring Master: The ring master initiates the ring identification
draft-maeurer-raw-ldacs-04.txt: data communication. The European ATM Master Plan foresees this
draft-melnikov-scram-sha-512-00.txt: Session Hash and Extended Master Secret Extension",
draft-melnikov-scram-sha3-512-00.txt: Session Hash and Extended Master Secret Extension",
draft-mglt-lurk-tls12-03.txt: 12.1. LURK Exchange for TLS RSA Master Secret with Proof of
draft-mglt-lurk-tls12-03.txt: 12.2. LURK Exchange for TLS RSA Extended Master Secret . . . . 26
draft-mglt-lurk-tls12-03.txt: 12.3. LURK Exchange for TLS RSA Extended Master Secret with
draft-mglt-lurk-tls12-03.txt: ## LURK Exchange for TLS RSA Master Secret
draft-mglt-lurk-tls12-03.txt:12.1. LURK Exchange for TLS RSA Master Secret with Proof of Handshake
draft-mglt-lurk-tls12-03.txt:12.2. LURK Exchange for TLS RSA Extended Master Secret
draft-mglt-lurk-tls12-03.txt: 1. Computing Master Secret
draft-mglt-lurk-tls12-03.txt:12.3. LURK Exchange for TLS RSA Extended Master Secret with proof of
draft-mglt-lurk-tls12-03.txt: 1. Computing Master Secret
draft-mglt-lurk-tls12-03.txt: Session Hash and Extended Master Secret Extension",
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: Protocol (VRRP) with sub-second Master convergence and defines the
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: detection of Master router failure by Backup routers.
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: to enable Backup routers to detect a failure of the Master router
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: (p2mp) BFD can enable faster detection of Master failure and thus
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: Master in some and as Backup in others. Supporting sub-second mode
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: session with its Master being the root and Backup routers being tails
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: [RFC5798] to bootstrap tail of the p2mp BFD session. Master
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: | Master Discriminator |
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: B(FD) - a one-bit flag that indicates that the Master
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: Master Discriminator - My Discriminator value allocated by the
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: The Master router that is configured to use p2mp BFD to support
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: value of My Discriminator MUST be set as the value of the Master
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: of the Master router it re-evaluates its role in the VRID. As a
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: result, the Backup router may become the Master router of the given
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: the new Master router MUST select My Discriminator and start
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: transmitting p2mp BFD control packets using Master IP address as the
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: new VRRP Master router that will bootstrap the new p2mp BFD session.
draft-mirsky-bfd-p2mp-vrrp-use-case-04.txt: MUST use the Master IP address as the source IP address.
draft-omara-sframe-00.txt: CTR +---------------> IV |Enc Key <----Master Key |
draft-orr-wlan-security-architectures-00.txt: generation of the Master Session Key (MSK) and Extended Master
draft-orr-wlan-security-architectures-00.txt: the Pairwise Master Key (PMK) (bits 0-255 of the AAA key). The
draft-pantos-hls-rfc8216bis-07.txt: 4.4.2. Media or Master Playlist Tags . . . . . . . . . . . . 15
draft-pantos-hls-rfc8216bis-07.txt: 4.4.6. Master Playlist Tags .. . . . . . . . . . . . . . . . 35
draft-pantos-hls-rfc8216bis-07.txt: 8.4. Master Playlist . . . . . .. . . . . . . . . . . . . . . . 67
draft-pantos-hls-rfc8216bis-07.txt: 8.5. Master Playlist with I-Frames . . . . . . . . . . . . . . 67
draft-pantos-hls-rfc8216bis-07.txt: 8.6. Master Playlist with Alternative Audio . . . . . . . . . 68
draft-pantos-hls-rfc8216bis-07.txt: 8.7. Master Playlist with Alternative Video . . . . . . . . . 68
draft-pantos-hls-rfc8216bis-07.txt: 8.8. Session Data in a Master Playlist . . . . . . . . . . . . 69
draft-pantos-hls-rfc8216bis-07.txt: A Playlist is either a Media Playlist or a Master Playlist. Both are
draft-pantos-hls-rfc8216bis-07.txt: A more complex presentation can be described by a Master Playlist. A
draft-pantos-hls-rfc8216bis-07.txt: Master Playlist provides a set of Variant Streams, each of which
draft-pantos-hls-rfc8216bis-07.txt: identify Media Segments. A Playlist is a Master Playlist if all URI
draft-pantos-hls-rfc8216bis-07.txt: either a Media Playlist or a Master Playlist; all other Playlists are
draft-pantos-hls-rfc8216bis-07.txt: These tags are allowed in both Media Playlists and Master Playlists.
draft-pantos-hls-rfc8216bis-07.txt: every Master Playlist. Its format is:
draft-pantos-hls-rfc8216bis-07.txt:4.4.2. Media or Master Playlist Tags
draft-pantos-hls-rfc8216bis-07.txt: The tags in this section can appear in either Master Playlists or
draft-pantos-hls-rfc8216bis-07.txt: Media Playlists. If one of these tags appears in a Master Playlist,
draft-pantos-hls-rfc8216bis-07.txt: it SHOULD NOT appear in any Media Playlist referenced by that Master
draft-pantos-hls-rfc8216bis-07.txt: If the EXT-X-INDEPENDENT-SEGMENTS tag appears in a Master Playlist,
draft-pantos-hls-rfc8216bis-07.txt: Master Playlist.
draft-pantos-hls-rfc8216bis-07.txt: in the Master Playlist. EXT-X-DEFINE tags containing the IMPORT
draft-pantos-hls-rfc8216bis-07.txt: attribute MUST NOT occur in Master Playlists; they are only
draft-pantos-hls-rfc8216bis-07.txt: declared in the Master Playlist, or if the Media Playlist was not
draft-pantos-hls-rfc8216bis-07.txt: loaded from a Master Playlist, the parser MUST fail to parse the
draft-pantos-hls-rfc8216bis-07.txt: A Media Playlist tag MUST NOT appear in a Master Playlist
draft-pantos-hls-rfc8216bis-07.txt: A Media Segment tag MUST NOT appear in a Master Playlist. Clients
draft-pantos-hls-rfc8216bis-07.txt: Master Playlist tags (Section 4.4.6).
draft-pantos-hls-rfc8216bis-07.txt:4.4.6. Master Playlist Tags
draft-pantos-hls-rfc8216bis-07.txt: Master Playlist tags define the Variant Streams, Renditions, and
draft-pantos-hls-rfc8216bis-07.txt: Master Playlist tags MUST NOT appear in a Media Playlist; clients
draft-pantos-hls-rfc8216bis-07.txt: MUST fail to parse any Playlist that contains both a Master Playlist
draft-pantos-hls-rfc8216bis-07.txt: Master Playlist contains two Renditions with the same NAME encoded
draft-pantos-hls-rfc8216bis-07.txt: If the Master Playlist is to be made available before all Media
draft-pantos-hls-rfc8216bis-07.txt: If the Master Playlist is to be made available before all Media
draft-pantos-hls-rfc8216bis-07.txt: GROUP-ID attribute of an EXT-X-MEDIA tag elsewhere in the Master
draft-pantos-hls-rfc8216bis-07.txt: GROUP-ID attribute of an EXT-X-MEDIA tag elsewhere in the Master
draft-pantos-hls-rfc8216bis-07.txt: GROUP-ID attribute of an EXT-X-MEDIA tag elsewhere in the Master
draft-pantos-hls-rfc8216bis-07.txt: in the Master Playlist. Having closed captions in one Variant
draft-pantos-hls-rfc8216bis-07.txt: alone, in that it does not apply to a particular URI in the Master
draft-pantos-hls-rfc8216bis-07.txt: A Master Playlist that specifies alternative VIDEO Renditions and
draft-pantos-hls-rfc8216bis-07.txt: carried in a Master Playlist.
draft-pantos-hls-rfc8216bis-07.txt: to be specified in a Master Playlist. This allows the client to
draft-pantos-hls-rfc8216bis-07.txt: A Master Playlist MUST NOT contain more than one EXT-X-SESSION-KEY
draft-pantos-hls-rfc8216bis-07.txt: a Master Playlist file that lists each Variant Stream to allow
draft-pantos-hls-rfc8216bis-07.txt: Master Playlists describe regular Variant Streams with EXT-X-STREAM-
draft-pantos-hls-rfc8216bis-07.txt: If any Media Playlist in a Master Playlist contains an EXT-X-
draft-pantos-hls-rfc8216bis-07.txt: PROGRAM-DATE-TIME tag, then all Media Playlists in that Master
draft-pantos-hls-rfc8216bis-07.txt: If any Media Playlist in a Master Playlist contains an EXT-X-
draft-pantos-hls-rfc8216bis-07.txt: SERVER-CONTROL tag, then all Media Playlists in that Master
draft-pantos-hls-rfc8216bis-07.txt: file so obtained is a Master Playlist, the client can select a
draft-pantos-hls-rfc8216bis-07.txt: Variant Stream to load from the Master Playlist.
draft-pantos-hls-rfc8216bis-07.txt: Master Playlist.
draft-pantos-hls-rfc8216bis-07.txt: A Master Playlist MUST indicate an EXT-X-VERSION of 7 or higher if it
draft-pantos-hls-rfc8216bis-07.txt: consider indicating an EXT-X-VERSION of 4 or higher in the Master
draft-pantos-hls-rfc8216bis-07.txt:8.4. Master Playlist
draft-pantos-hls-rfc8216bis-07.txt:8.5. Master Playlist with I-Frames
draft-pantos-hls-rfc8216bis-07.txt:8.6. Master Playlist with Alternative Audio
draft-pantos-hls-rfc8216bis-07.txt:8.7. Master Playlist with Alternative Video
draft-pantos-hls-rfc8216bis-07.txt:8.8. Session Data in a Master Playlist
draft-pantos-hls-rfc8216bis-07.txt: Media Playlist (Rendition) in the Master Playlist, except for the
draft-pantos-hls-rfc8216bis-07.txt: All Renditions in a Master Playlist are updated in sync, within an
draft-pep-email-00.txt: 7.4. Option "Blacklist Keys" . . . . . . . .. . . . . . . . . . 26
draft-pep-email-00.txt:7.4. Option "Blacklist Keys"
draft-sarikaya-t2trg-sbootstrapping-08.txt: Master Key, Network Key Sequence, Network Mesh-Local ULA, Border
draft-selander-ace-coap-est-oscore-03.txt: keying material (notably, the OSCORE Master Secret, see [RFC8613])
draft-selander-ace-coap-est-oscore-03.txt: client and EST-oscore server need access to the same OSCORE Master
draft-sheffer-uta-bcp195bis-00.txt: Session Hash and Extended Master Secret Extension",
draft-sheffer-uta-rfc7525bis-00.txt: Session Hash and Extended Master Secret Extension",
draft-smyshlyaev-tls12-gost-suites-08.txt: Session Hash and Extended Master Secret Extension",
draft-thubert-raw-technologies-05.txt: data communication. The European ATM Master Plan foresees this
draft-tiloca-ace-group-oscore-profile-03.txt: string concatenation. Also, 'IKM' is the OSCORE Master Secret
draft-tiloca-ace-group-oscore-profile-03.txt: derivation process uses also the Master Secret of the OSCORE group,
draft-tiloca-ace-group-oscore-profile-03.txt: received from the AS. The derivation process uses also the Master
draft-tiloca-ace-group-oscore-profile-03.txt: Security Context based on a shared Master Secret and a set of other
draft-tiloca-ace-group-oscore-profile-03.txt: the Master Secret in OSCORE (see Appendix A.3.3 and Appendix A.3.4).
draft-tiloca-ace-group-oscore-profile-03.txt: Security Context using the pop-key as part of the OSCORE Master
draft-tiloca-ace-group-oscore-profile-03.txt: information related to the OSCORE group, i.e. the Master Secret and
draft-tiloca-ace-group-oscore-profile-03.txt: lacks the Master Secret used in the OSCORE group.
draft-tiloca-ace-group-oscore-profile-03.txt: o The Client MUST set the updated Master Salt of the pairwise OSCORE
draft-tiloca-ace-group-oscore-profile-03.txt: (optional) Master Salt in the pairwise OSCORE Security Context;
draft-tiloca-ace-group-oscore-profile-03.txt: and iii) GMSalt is the (optional) Master Salt in the Group OSCORE
draft-tiloca-ace-group-oscore-profile-03.txt: OSCORE group. The concatenation occurs in this order: Master Salt
draft-tiloca-ace-group-oscore-profile-03.txt: o The Client MUST set the Master Secret of the pairwise OSCORE
draft-tiloca-ace-group-oscore-profile-03.txt: from the AS in Appendix A.2.2; while ii) GMSec is the Master
draft-tiloca-ace-group-oscore-profile-03.txt: o The RS MUST set the new Master Salt of the pairwise OSCORE
draft-tiloca-ace-group-oscore-profile-03.txt: Master Salt in the pairwise OSCORE Security Context as specified
draft-tiloca-ace-group-oscore-profile-03.txt: Client; and iii) GMSalt is the (optional) Master Salt in the Group
draft-tiloca-ace-group-oscore-profile-03.txt: the OSCORE group. The concatenation occurs in this order: Master
draft-tiloca-ace-group-oscore-profile-03.txt: o The RS MUST set the Master Secret of the pairwise OSCORE Security
draft-tiloca-ace-group-oscore-profile-03.txt: Master Secret of the Group OSCORE Security Context, which is known
draft-touch-tcpm-ao-test-vectors-00.txt: [RFC5925]. The Master Key is used to derive the traffic keys
draft-tschofenig-rats-psa-token-05.txt: Blacklist | ..------------+------. .----------+----.
draft-unyte-netconf-distributed-notif-00.txt: Master: is the Publisher that interacts with the Subscriber to deal
draft-unyte-netconf-distributed-notif-00.txt: Agent: is the Publisher that interacts with the Master to deal with
draft-unyte-netconf-distributed-notif-00.txt: according to the subscription. The Publisher is either in the Master
draft-unyte-netconf-distributed-notif-00.txt: or Agent role. The Master knows all the capabilities that his Agents
draft-unyte-netconf-distributed-notif-00.txt: Master and disassembles the Global Subscription to multiple Component
draft-unyte-netconf-distributed-notif-00.txt: | | Publisher(Master) | | |
draft-unyte-netconf-distributed-notif-00.txt: Master and Agents interact with each other in several ways:
draft-unyte-netconf-distributed-notif-00.txt: o Agents need to register at the Master at the beginning of their
draft-unyte-netconf-distributed-notif-00.txt: o Contracts are created between the Master and each Agent on the
draft-unyte-netconf-distributed-notif-00.txt: o The Master relays the component subscriptions to the Agents.
draft-unyte-netconf-distributed-notif-00.txt: the Master. The status of the overall subscription is maintained
draft-unyte-netconf-distributed-notif-00.txt: by the Master. The Master is responsible for notifying the
draft-unyte-netconf-distributed-notif-00.txt: operational information between Master and Agent is out-of-scope of
draft-unyte-netconf-distributed-notif-00.txt: The Collector can only subscribe to the Master. This requires the
draft-unyte-netconf-distributed-notif-00.txt: Master to:
draft-unyte-netconf-distributed-notif-00.txt: o Inherit the Global Subscription properties from Publisher Master
draft-unyte-netconf-distributed-notif-00.txt: In addition to sending event records to Receivers, the Master MUST
draft-unyte-netconf-distributed-notif-00.txt: Master.
draft-unyte-netconf-distributed-notif-00.txt: | Receiver | | (Master) | | (Agent) |
draft-unyte-netconf-distributed-notif-00.txt: the Master with a successful response. An example of using NETCONF:
draft-unyte-netconf-distributed-notif-00.txt: by the Master. The notification, Figure 7 for example, indicates the
draft-unyte-netconf-distributed-notif-00.txt: | | | (Master) | | (Agent) |
draft-unyte-netconf-multi-stream-originators-00.txt: Master: is the Publisher that interacts with the Subscriber to deal
draft-unyte-netconf-multi-stream-originators-00.txt: Agent: is the Publisher that interacts with the Master to deal with
draft-unyte-netconf-multi-stream-originators-00.txt: Master role and the Agent role. The Master knows all the
draft-unyte-netconf-multi-stream-originators-00.txt: information to the Master. The Master disassembles the Global
draft-unyte-netconf-multi-stream-originators-00.txt: | | Publisher(Master) | | |
draft-unyte-netconf-multi-stream-originators-00.txt: Master and Agents may interact with each other in several ways:
draft-unyte-netconf-multi-stream-originators-00.txt: the Master, so the Master is aware of them and of life-cycle
draft-unyte-netconf-multi-stream-originators-00.txt: o Contracts are needed between the Master and each Agent on the
draft-unyte-netconf-multi-stream-originators-00.txt: o The Master relays the component subscriptions to the Agents.
draft-unyte-netconf-multi-stream-originators-00.txt: Master. The status of the overall subscription is maintained by
draft-unyte-netconf-multi-stream-originators-00.txt: the Master. The Master is also responsible for notifying the
draft-unyte-netconf-multi-stream-originators-00.txt: operational information between Master and Agent is out-of-scope of
draft-unyte-netconf-multi-stream-originators-00.txt: coordination on the Master.
draft-unyte-netconf-multi-stream-originators-00.txt: The Collector can only subscribe to the Master. This requires the
draft-unyte-netconf-multi-stream-originators-00.txt: Master to:
draft-unyte-netconf-multi-stream-originators-00.txt: The Master can keep track of the mapping between the resource and the
draft-unyte-netconf-multi-stream-originators-00.txt: rests with the Resource-Location Table. A Master can decide to not
draft-unyte-netconf-multi-stream-originators-00.txt: Subscription can be served locally by the Master. Similarly, it can
draft-unyte-netconf-multi-stream-originators-00.txt: from the Master. It can also decide to decompose the Global
draft-unyte-netconf-multi-stream-originators-00.txt: Master, not by the subscriber.
draft-unyte-netconf-multi-stream-originators-00.txt: In addition to sending event records to receivers, the Master MUST
draft-unyte-netconf-multi-stream-originators-00.txt: Master.
draft-unyte-netconf-multi-stream-originators-00.txt: | Receiver | | (Master) | | (Agent) |
draft-unyte-netconf-multi-stream-originators-00.txt: the Master with a successful response. An example of using NETCONF
draft-unyte-netconf-multi-stream-originators-00.txt: by the Master. The notification, Figure 7 for example, indicates the
draft-unyte-netconf-multi-stream-originators-00.txt: | | | (Master) | | (Agent) |
draft-urien-tls-im-03.txt: 2.4.2 EEMS: Early Exporter Master Secret ................... 6 
draft-urien-tls-im-03.txt: 4.5 EEMS: Early Exporter Master Secret.......................... 9 
draft-urien-tls-im-03.txt: - EEMS: Early Exporter Master Secret 
draft-urien-tls-im-03.txt: 2.4.2 EEMS: Early Exporter Master Secret 
draft-urien-tls-im-03.txt: Output: Early Exporter Master Secret or Failure 
draft-urien-tls-im-03.txt:4.5 EEMS: Early Exporter Master Secret 
draft-urien-tls-im-03.txt: Rx: [Early Exporter Master Secret] 9000 
draft-urien-tls-im-03.txt: [Early Exporter Master Secret] = 
draft-vanrein-httpauth-sasl-04.txt: Session Hash and Extended Master Secret Extension",
draft-vcgtf-crypto-assets-security-considerations-06.txt: | Master Seed | A seed, e.g. random number, to generate a |
draft-wang-tls-raw-public-key-with-ibc-12.txt: PKG has in possession a pair of Master Public Key and Master Secret
draft-wang-tls-raw-public-key-with-ibc-12.txt: the Master Secret key, while the Master Public key is used together
draft-wang-tls-raw-public-key-with-ibc-12.txt: Master Public Key (MPK) are provisioned to both client and server.
draft-yaoyuan-dnsext-idr-adr-00.txt:4.1. Processing By Primary Master Servers
draft-yiakoumis-network-tokens-01.txt: 2.1.2. Firewall Whitelist .. . . . . . . . . . . . . . . . . 6
draft-yiakoumis-network-tokens-01.txt:2.1.2. Firewall Whitelist