1.1 Glossary
This document uses the following terms:
access point: A network access server (NAS) that is implementing [IEEE802.11-2012], connecting wireless devices to form a wireless network.
authentication: The ability of one entity to determine the identity of another entity by proving an identity to a server while providing key material that binds the identity to subsequent communications.
binary large object (BLOB): A discrete packet of data that is stored in a database and is treated as a sequence of uninterpreted bytes.
certificate: A certificate is a collection of attributes and extensions that can be stored persistently. The set of attributes in a certificate can vary depending on the intended usage of the certificate. A certificate securely binds a public key to the entity that holds the corresponding private key. A certificate is commonly used for authentication and secure exchange of information on open networks, such as the Internet, extranets, and intranets. Certificates are digitally signed by the issuing certification authority (CA) and can be issued for a user, a computer, or a service. The most widely accepted format for certificates is defined by the ITU-T X.509 version 3 international standards. For more information about attributes and extensions, see [RFC3280] and [X509] sections 7 and 8.
cipher suite: A set of cryptographic algorithms used to encrypt and decrypt files and messages.
cleartext: In cryptography, cleartext is the form of a message (or data) that is transferred or stored without cryptographic protection.
context handle: An opaque handle returned by a TLS implementation to the higher layer (PEAP layer) after a TLS session is established successfully. This is a handle to the TLS session's security parameter structure ([RFC5246] section A.6) maintained by the TLS layer. As a TLS implementation can handle multiple sessions simultaneously, it relies on the context handle to identify the corresponding session when receiving calls to encrypt and decrypt message functions from the higher layer.
decryption: In cryptography, the process of transforming encrypted information to its original clear text form.
EAP: See Extensible Authentication Protocol (EAP).
EAP identity: The identity of the Extensible Authentication Protocol (EAP) peer as specified in [RFC3748].
EAP method: An authentication mechanism that integrates with the Extensible Authentication Protocol (EAP); for example, EAP-TLS, Protected EAP v0 (PEAPv0), EAP-MSCHAPv2, and so on.
EAP peer: A network access client that is requesting access to a network using EAP as the authentication method
EAP server: The backend authentication server; typically a RADIUS (as specified in [RFC2865]) server.
encryption: In cryptography, the process of obscuring information to make it unreadable without special knowledge.
Extensible Authentication Protocol (EAP): A framework for authentication that is used to provide a pluggable model for adding authentication protocols for use in network access authentication, as specified in [RFC3748].
fast reconnect: A shortcut negotiation that capitalizes on information exchanged in the initial authentication to expedite the reestablishment of a session.
Group Policy: A mechanism that allows the implementer to specify managed configurations for users and computers in an Active Directory service environment.
handshake: An initial negotiation between a peer and an authenticator that establishes the parameters of their transactions.
inner EAP method: An Extensible Authentication Protocol (EAP) method that is tunneled within another EAP method.
man in the middle (MITM): An attack that deceives a server or client into accepting an unauthorized upstream host as the actual legitimate host. Instead, the upstream host is an attacker's host that is manipulating the network so that the attacker's host appears to be the desired destination. This enables the attacker to decrypt and access all network traffic that would go to the legitimate host. The attacker is able to read, insert, and modify at-will messages between two hosts without either party knowing that the link between them is compromised.
MPPE Keys: Specifies the key material generated by the EAP methods which can be used to perform data encryption between peer and NAS. There are two types MPPE Keys based on the direction of data flow they are used with - MPPE Send Key and MPPE Receive key. Each EAP method has its own mechanism of generating these keys. For example, section 2.3 of [RFC5216] specifies the mechanism to generate the MPPE Keys (MS-MPPE-Send-Key and MS-MPPE-Recv-Key) for EAP-TLS authentication protocol.
Network Access Identifier (NAI): The identity included within EAP–Response/Identity (section 5.1 of [RFC3748]). As defined in [RFC4282], this includes an optional username portion as well as a realm portion.
network access server (NAS): A computer server that provides an access service for a user who is trying to access a network. A NAS operates as a client of RADIUS. The RADIUS client is responsible for passing user information to designated RADIUS servers and then acting on the response returned by the RADIUS server. Examples of a NAS include: a VPN server, Wireless Access Point, 802.1x-enabled switch, or Network Access Protection (NAP) server.
network byte order: The order in which the bytes of a multiple-byte number are transmitted on a network, most significant byte first (in big-endian storage). This does not always match the order in which numbers are normally stored in memory for a particular processor.
padding: Bytes that are inserted in a data stream to maintain alignment of the protocol requests on natural boundaries.
PEAP Peer: An implementation of a PEAP method on a EAP peer that takes care of the PEAP method peer-side requirements.
PEAP Server: An implementation of a PEAP method on a EAP server that takes care of the PEAP method server-side requirements.
peer: The entity being authenticated by the authenticator.
phase: A series of exchanges that provide a particular set of security services (for example, authentication or creation of security associations (SAs)).
realm: An administrative boundary that uses one set of authentication servers to manage and deploy a single set of unique identifiers. A realm is a unique logon space.
session: In the Challenge-Handshake Authentication Protocol (CHAP), a session is a lasting connection between a peer and an authenticator.
statement of health (SoH): A collection of data generated by a system health entity, as specified in [TNC-IF-TNCCSPBSoH], which defines the health state of a machine. The data is interpreted by a Health Policy Server, which determines whether the machine is healthy or unhealthy according to the policies defined by an administrator.
Transport Layer Security (TLS): A security protocol that supports confidentiality and integrity of messages in client and server applications communicating over open networks. TLS supports server and, optionally, client authentication by using X.509 certificates (as specified in [X509]). TLS is standardized in the IETF TLS working group.
trust root: A collection of root CA keys trusted by the RP. A store within the computer of a relying party that is protected from tampering and in which the root keys of all root CAs are held. Those root keys are typically encoded within self-signed certificates, and the contents of a trust root are therefore sometimes called root certificates.
tunnel: The encapsulation of one network protocol within another.
type-length-value (TLV): Information element encoded within [MS-PEAP]. Type and length fields are a fixed size (that is, 1 to 4 bytes), and the value field is variable. "Type" indicates what kind of field is encoded; "Length" indicates the size of "Value"; "Value" defines the data portion of the TLV element.
virtual private network (VPN): A network that provides secure access to a private network over public infrastructure.
X.509: An ITU-T standard for public key infrastructure subsequently adapted by the IETF, as specified in [RFC3280].
MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.