--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Hartman, Ed.
+Request for Comments: 7055 Painless Security
+Category: Standards Track J. Howlett
+ISSN: 2070-1721 JANET(UK)
+ December 2013
+
+
+ A GSS-API Mechanism for the Extensible Authentication Protocol
+
+Abstract
+
+ This document defines protocols, procedures, and conventions to be
+ employed by peers implementing the Generic Security Service
+ Application Program Interface (GSS-API) when using the Extensible
+ Authentication Protocol mechanism. Through the GS2 family of
+ mechanisms defined in RFC 5801, these protocols also define how
+ Simple Authentication and Security Layer (SASL) applications use the
+ Extensible Authentication Protocol.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7055.
+
+Copyright Notice
+
+ Copyright (c) 2013 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Hartman & Howlett Standards Track [Page 1]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Discovery ..................................................4
+ 1.2. Authentication .............................................4
+ 1.3. Secure Association Protocol ................................6
+ 2. Requirements Notation ...........................................6
+ 3. EAP Channel Binding and Naming ..................................6
+ 3.1. Mechanism Name Format ......................................7
+ 3.2. Internationalization of Names .............................10
+ 3.3. Exported Mechanism Names ..................................10
+ 3.4. Acceptor Name RADIUS AVP ..................................11
+ 3.5. Proxy Verification of Acceptor Name .......................11
+ 4. Selection of EAP Method ........................................12
+ 5. Context Tokens .................................................13
+ 5.1. Mechanisms and Encryption Types ...........................14
+ 5.2. Processing Received Tokens ................................15
+ 5.3. Error Subtokens ...........................................16
+ 5.4. Initial State .............................................16
+ 5.4.1. Vendor Subtoken ....................................17
+ 5.4.2. Acceptor Name Request ..............................17
+ 5.4.3. Acceptor Name Response .............................18
+ 5.5. Authenticate State ........................................18
+ 5.5.1. EAP Request Subtoken ...............................19
+ 5.5.2. EAP Response Subtoken ..............................19
+ 5.6. Extensions State ..........................................20
+ 5.6.1. Flags Subtoken .....................................20
+ 5.6.2. GSS Channel Bindings Subtoken ......................20
+ 5.6.3. MIC Subtoken .......................................21
+ 5.7. Example Token .............................................22
+ 5.8. Context Options ...........................................23
+ 6. Acceptor Services ..............................................23
+ 6.1. GSS-API Channel Binding ...................................24
+ 6.2. Per-Message Security ......................................24
+ 6.3. Pseudorandom Function .....................................24
+ 7. IANA Considerations ............................................25
+ 7.1. OID Registry ..............................................25
+ 7.2. RFC 4121 Token Identifiers ................................26
+ 7.3. GSS-EAP Subtoken Types ....................................26
+ 7.4. RADIUS Attribute Assignments ..............................27
+ 7.5. Registration of the EAP-AES128 SASL Mechanisms ............28
+ 7.6. GSS-EAP Errors ............................................28
+ 7.7. GSS-EAP Context Flags .....................................30
+ 8. Security Considerations ........................................30
+ 9. Acknowledgements ...............................................32
+ 10. References ....................................................32
+ Appendix A. Pre-publication RADIUS VSA ............................33
+
+
+
+
+Hartman & Howlett Standards Track [Page 2]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+1. Introduction
+
+ The Application Bridging for Federated Access Beyond Web (ABFAB)
+ document [ABFAB-ARCH] describes an architecture for providing
+ federated access management to applications using the Generic
+ Security Service Application Programming Interface (GSS-API)
+ [RFC2743] and Simple Authentication and Security Layer (SASL)
+ [RFC4422]. This specification provides the core mechanism for
+ bringing federated authentication to these applications.
+
+ The Extensible Authentication Protocol (EAP) [RFC3748] defines a
+ framework for authenticating a network access client and server in
+ order to gain access to a network. A variety of different EAP
+ methods are in wide use; one of EAP's strengths is that for most
+ types of credentials in common use, there is an EAP method that
+ permits the credential to be used.
+
+ EAP is often used in conjunction with a backend Authentication,
+ Authorization and Accounting (AAA) server via RADIUS [RFC3579] or
+ Diameter [RFC4072]. In this mode, the Network Access Server (NAS)
+ simply tunnels EAP packets over the backend authentication protocol
+ to a home EAP/AAA server for the client. After EAP succeeds, the
+ backend authentication protocol is used to communicate key material
+ to the NAS. In this mode, the NAS need not be aware of or have any
+ specific support for the EAP method used between the client and the
+ home EAP server. The client and EAP server share a credential that
+ depends on the EAP method; the NAS and AAA server share a credential
+ based on the backend authentication protocol in use. The backend
+ authentication server acts as a trusted third party, enabling network
+ access even though the client and NAS may not actually share any
+ common authentication methods. As described in the architecture
+ document [ABFAB-ARCH], using AAA proxies, this mode can be extended
+ beyond one organization to provide federated authentication for
+ network access.
+
+ The GSS-API provides a generic framework for applications to use
+ security services including authentication and per-message data
+ security. Between protocols that support GSS-API directly or
+ protocols that support SASL [RFC4422], many application protocols can
+ use GSS-API for security services. However, with the exception of
+ Kerberos [RFC4121], few GSS-API mechanisms are in wide use on the
+ Internet. While GSS-API permits an application to be written
+ independent of the specific GSS-API mechanism in use, there is no
+ facility to separate the server from the implementation of the
+ mechanism as there is with EAP and backend authentication servers.
+
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 3]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ The goal of this specification is to combine GSS-API's support for
+ application protocols with EAP/AAA's support for common credential
+ types and for authenticating to a server without requiring that
+ server to specifically support the authentication method in use. In
+ addition, this specification supports the architectural goal of
+ transporting attributes about subjects to relying parties. Together
+ this combination will provide federated authentication and
+ authorization for GSS-API applications. This specification meets the
+ applicability requirements for EAP to application authentication
+ [RFC7057].
+
+ This mechanism is a GSS-API mechanism that encapsulates an EAP
+ conversation. From the perspective of RFC 3748, this specification
+ defines a new lower-layer protocol for EAP. From the perspective of
+ the application, this specification defines a new GSS-API mechanism.
+
+ Section 1.3 of [RFC5247] outlines the typical conversation between
+ EAP peers where an EAP key is derived:
+
+ Phase 0: Discovery
+ Phase 1: Authentication
+ 1a: EAP authentication
+ 1b: AAA Key Transport (optional)
+ Phase 2: Secure Association Protocol
+ 2a: Unicast Secure Association
+ 2b: Multicast Secure Association (optional)
+
+1.1. Discovery
+
+ GSS-API peers discover each other and discover support for GSS-API in
+ an application-dependent mechanism. SASL [RFC4422] describes how
+ discovery of a particular SASL mechanism such as a GSS-API EAP
+ mechanism is conducted. The Simple and Protected Negotiation
+ mechanism (SPNEGO) [RFC4178] provides another approach for
+ discovering what GSS-API mechanisms are available. The specific
+ approach used for discovery is out of scope for this mechanism.
+
+1.2. Authentication
+
+ GSS-API authenticates a party called the "GSS-API initiator" to the
+ GSS-API acceptor, optionally providing authentication of the acceptor
+ to the initiator. Authentication starts with a mechanism-specific
+ message called a "context token" sent from the initiator to the
+ acceptor. The acceptor responds, followed by the initiator, and so
+ on until authentication succeeds or fails. GSS-API context tokens
+ are reliably delivered by the application using GSS-API. The
+ application is responsible for in-order delivery and retransmission.
+
+
+
+
+Hartman & Howlett Standards Track [Page 4]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ EAP authenticates a party called a "peer" to a party called the "EAP
+ server". A third party called an "EAP pass-through authenticator"
+ may decapsulate EAP messages from a lower layer and re-encapsulate
+ them into a AAA protocol. The term EAP authenticator refers to
+ whichever of the pass-through authenticator or EAP server receives
+ the lower-layer EAP packets. The first EAP message travels from the
+ authenticator to the peer; a GSS-API message is sent from the
+ initiator to acceptor to prompt the authenticator to send the first
+ EAP message. The EAP peer maps onto the GSS-API initiator. The role
+ of the GSS-API acceptor is split between the EAP authenticator and
+ the EAP server. When these two entities are combined, the division
+ resembles GSS-API acceptors in other mechanisms. When a more typical
+ deployment is used and there is a pass-through authenticator, most
+ context establishment takes place on the EAP server and per-message
+ operations take place on the authenticator. EAP messages from the
+ peer to the authenticator are called responses; messages from the
+ authenticator to the peer are called requests.
+
+ Because GSS-API applications provide guaranteed delivery of context
+ tokens, the EAP retransmission timeout MUST be infinite and the EAP
+ layer MUST NOT retransmit a message.
+
+ This specification permits a GSS-API acceptor to hand off the
+ processing of the EAP packets to a remote EAP server by using AAA
+ protocols such as RADIUS, Transport Layer Security (TLS) Encryption
+ thereof [RFC6929], or Diameter. In this case, the GSS-API acceptor
+ acts as an EAP pass-through authenticator. The pass-through
+ authenticator is responsible for retransmitting AAA messages if a
+ response is not received from the AAA server. If a response cannot
+ be received, then the authenticator generates an error at the GSS-API
+ level. If EAP authentication is successful, and where the chosen EAP
+ method supports key derivation, EAP keying material may also be
+ derived. If a AAA protocol is used, this can also be used to
+ replicate the EAP Key from the EAP server to the EAP authenticator.
+
+ See Section 5 for details of the authentication exchange.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 5]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+1.3. Secure Association Protocol
+
+ After authentication succeeds, GSS-API provides a number of per-
+ message security services that can be used:
+
+ GSS_Wrap() provides integrity and optional confidentiality for a
+ message.
+
+ GSS_GetMIC() provides integrity protection for data sent
+ independently of the GSS-API
+
+ GSS_Pseudo_random [RFC4401] provides key derivation functionality.
+
+ These services perform a function similar to secure association
+ protocols in network access. Like secure association protocols,
+ these services need to be performed near the authenticator/acceptor
+ even when a AAA protocol is used to separate the authenticator from
+ the EAP server. The key used for these per-message services is
+ derived from the EAP key; the EAP peer and authenticator derive this
+ key as a result of a successful EAP authentication. In the case that
+ the EAP authenticator is acting as a pass-through, it obtains it via
+ the AAA protocol. See Section 6 for details.
+
+2. Requirements Notation
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. EAP Channel Binding and Naming
+
+ EAP authenticates a user to a realm. The peer knows that it has
+ exchanged authentication with an EAP server in a given realm. Today,
+ the peer does not typically know which NAS it is talking to securely.
+ That is often fine for network access. However, privileges to
+ delegate to a chat server seem very different than privileges for a
+ file server or trading site. Also, an EAP peer knows the identity of
+ the home realm, but perhaps not even the visited realm.
+
+ In contrast, GSS-API takes a name for both the initiator and acceptor
+ as inputs to the authentication process. When mutual authentication
+ is used, both parties are authenticated. The granularity of these
+ names is somewhat mechanism dependent. In the case of the Kerberos
+ mechanism, the acceptor name typically identifies both the protocol
+ in use (such as IMAP) and the specific instance of the service being
+ connected to. The acceptor name almost always identifies the
+ administrative domain providing service.
+
+
+
+
+Hartman & Howlett Standards Track [Page 6]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ A GSS-API EAP mechanism needs to provide GSS-API naming semantics in
+ order to work with existing GSS-API applications. EAP channel
+ binding [RFC6677] is used to provide GSS-API naming semantics.
+ Channel binding sends a set of attributes from the peer to the EAP
+ server either as part of the EAP conversation or as part of a secure
+ association protocol. In addition, attributes are sent in the
+ backend authentication protocol from the authenticator to the EAP
+ server. The EAP server confirms the consistency of these attributes.
+ Confirming attribute consistency also involves checking consistency
+ against a local policy database as discussed in Section 3.5. In
+ particular, the peer sends the name of the acceptor it is
+ authenticating to as part of channel binding. The acceptor sends its
+ full name as part of the backend authentication protocol. The EAP
+ server confirms consistency of the names.
+
+ EAP channel binding is easily confused with a facility in GSS-API
+ also called "channel binding". GSS-API channel binding provides
+ protection against man-in-the-middle attacks when GSS-API is used as
+ authentication inside some tunnel; it is similar to a facility called
+ "cryptographic binding" in EAP. See [RFC5056] for a discussion of
+ the differences between these two facilities and Section 6.1 for how
+ GSS-API channel binding is handled in this mechanism.
+
+3.1. Mechanism Name Format
+
+ Before discussing how the initiator and acceptor names are validated
+ in the AAA infrastructure, it is necessary to discuss what composes a
+ name for an EAP GSS-API mechanism. GSS-API permits several types of
+ generic names to be imported using GSS_Import_name(). Once a
+ mechanism is chosen, these names are converted into a mechanism-
+ specific name called a "Mechanism Name". Note that a Mechanism Name
+ is the name of an initiator or acceptor, not of a GSS-API mechanism.
+ This section first discusses the mechanism name form and then
+ discusses what name forms are supported.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 7]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ The string representation of the GSS-EAP mechanism name has the
+ following ABNF [RFC5234] representation:
+
+ char-normal = %x00-2E/%x30-3F/%x41-5B/%x5D-FF
+ char-escaped = "\" %x2F / "\" %x40 / "\" %x5C
+ name-char = char-normal / char-escaped
+ name-string = 1*name-char
+ user-or-service = name-string
+ host = [name-string]
+ realm = name-string
+ service-specific = name-string
+ service-specifics = service-specific 0*("/" service-specifics)
+ name = user-or-service ["/" host [ "/" service-specifics]] [ "@"
+ realm ]
+
+ Special characters appearing in a name can be backslash escaped to
+ avoid their special meanings. For example, "\\" represents a literal
+ backslash. This escaping mechanism is a property of the string
+ representation; if the components of a name are transported in some
+ mechanism that will keep them separate without backslash escaping,
+ then backslash SHOULD have no special meaning.
+
+ The user-or-service component is similar to the portion of a network
+ access identifier (NAI) before the '@' symbol for initiator names and
+ the service name from the registry of GSS-API host-based services in
+ the case of acceptor names [GSS-IANA]. The NAI specification
+ provides rules for encoding and string preparation in order to
+ support internationalization of NAIs; implementations of this
+ mechanism MUST NOT prepare the user-or-service according to these
+ rules; see Section 3.2 for internationalization of this mechanism.
+ The host portion is empty for initiators and typically contains the
+ domain name of the system on which an acceptor service is running.
+ Some services MAY require additional parameters to distinguish the
+ entity being authenticated against. Such parameters are encoded in
+ the service-specifics portion of the name. The EAP server MUST
+ reject authentication of any acceptor name that has a non-empty
+ service-specifics component unless the EAP server understands the
+ service-specifics and authenticates them. The interpretation of the
+ service-specifics is scoped by the user-or-service portion. The
+ realm is similar to the realm portion of a NAI for initiator names;
+ again the NAI specification's internationalization rules MUST NOT be
+ applied to the realm. The realm is the administrative realm of a
+ service for an acceptor name.
+
+ The string representation of this name form is designed to be
+ generally compatible with the string representation of Kerberos names
+ defined in [RFC1964].
+
+
+
+
+Hartman & Howlett Standards Track [Page 8]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ The GSS_C_NT_USER_NAME form represents the name of an individual
+ user. From the standpoint of this mechanism, it may take the form of
+ either an undecorated user name or a name semantically similar to a
+ network access identifier (NAI) [RFC4282]. The name is split at the
+ first at-sign ('@') into the part preceding the realm, which is the
+ user-or-service portion of the mechanism name, and the realm portion,
+ which is the realm portion of the mechanism name.
+
+ The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running
+ on a host; it is textually represented as "service@host". This name
+ form is required by most SASL profiles and is used by many existing
+ applications that use the Kerberos GSS-API mechanism. While support
+ for this name form is critical, it presents an interesting challenge
+ in terms of EAP channel binding. Consider a case where the server
+ communicates with a "server proxy," or a AAA server near the server.
+ That server proxy communicates with the EAP server. The EAP server
+ and server proxy are in different administrative realms. The server
+ proxy is in a position to verify that the request comes from the
+ indicated host. However, the EAP server cannot make this
+ determination directly. So, the EAP server needs to determine
+ whether to trust the server proxy to verify the host portion of the
+ acceptor name. This trust decision depends both on the host name and
+ the realm of the server proxy. In effect, the EAP server decides
+ whether to trust that the realm of the server proxy is the right
+ realm for the given hostname and then makes a trust decision about
+ the server proxy itself. The same problem appears in Kerberos:
+ there, clients decide what Kerberos realm to trust for a given
+ hostname. The service portion of this name is imported into the
+ user-or-service portion of the mechanism name; the host portion is
+ imported into the host portion of the mechanism name. The realm
+ portion is empty. However, authentication will typically fail unless
+ some AAA component indicates the realm to the EAP server. If the
+ application server knows its realm, then it should be indicated in
+ the outgoing AAA request. Otherwise, a proxy SHOULD add the realm.
+ An alternate form of this name type MAY be used on acceptors; in this
+ case, the name form is "service" with no host component. This is
+ imported with the service as user-or-service and an empty host and
+ realm portion. This form is useful when a service is unsure which
+ name an initiator knows it by.
+
+ If the null name type or the GSS_EAP_NT_EAP_NAME (OID
+ 1.3.6.1.5.5.15.2.1) (see Section 7.1 ) is imported, then the string
+ representation above should be directly imported. Mechanisms MAY
+ support the GSS_KRB5_NT_KRB5_PRINCIPAL_NAME name form with the OID
+ {iso(1) member-body(2) United States(840) mit(113554) infosys(1)
+ gssapi(2) krb5(2) krb5_name(1)}. In many circumstances, Kerberos
+ GSS-API mechanism names will behave as expected when used with the
+ GSS-API EAP mechanism, but there are some differences that may cause
+
+
+
+Hartman & Howlett Standards Track [Page 9]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ some confusion. If an implementation does support importing Kerberos
+ names it SHOULD fail the import if the Kerberos name is not
+ syntactically a valid GSS-API EAP mechanism name as defined in this
+ section.
+
+3.2. Internationalization of Names
+
+ For the most part, GSS-EAP names are transported in other protocols;
+ those protocols define the internationalization semantics. For
+ example, if a AAA server wishes to communicate the user-or-service
+ portion of the initiator name to an acceptor, it does so using
+ existing mechanisms in the AAA protocol. Existing
+ internationalization rules are applied. Similarly, within an
+ application, existing specifications such as [RFC5178] define the
+ encoding of names that are imported and displayed with the GSS-API.
+
+ This mechanism does introduce a few cases where name components are
+ sent. In these cases, the encoding of the string is UTF-8. Senders
+ SHOULD NOT normalize or map strings before sending. These strings
+ include RADIUS attributes introduced in Section 3.4.
+
+ When comparing the host portion of a GSS-EAP acceptor name supplied
+ in EAP channel binding by a peer to that supplied by an acceptor, EAP
+ servers SHOULD prepare the host portion according to [RFC5891] prior
+ to comparison. Applications MAY prepare domain names prior to
+ importing them into this mechanism.
+
+3.3. Exported Mechanism Names
+
+ GSS-API provides the GSS_Export_name call. This call can be used to
+ export the binary representation of a name. This name form can be
+ stored on access control lists for binary comparison.
+
+ The exported name token MUST use the format described in Section 3.2
+ of RFC 2743. The mechanism specific portion of this name token is
+ the string format of the mechanism name described in Section 3.1.
+
+ RFC 2744 [RFC2744] places the requirement that the result of
+ importing a name, canonicalizing it to a Mechanism Name and then
+ exporting it needs to be the same as importing that name, obtaining
+ credentials for that principal, initiating a context with those
+ credentials and exporting the name on the acceptor. In practice, GSS
+ mechanisms often, but not always, meet this requirement. For names
+ expected to be used as initiator names, this requirement is met.
+ However, permitting empty host and realm components when importing
+ host-based services may make it possible for an imported name to
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 10]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ differ from the exported name actually used. Other mechanisms such
+ as Kerberos have similar situations where imported and exported names
+ may differ.
+
+3.4. Acceptor Name RADIUS AVP
+
+ See Section 7.4 for registrations of RADIUS attribute types to carry
+ the acceptor service name. All the attribute types registered in
+ that section are strings. See Section 3.1 for details of the values
+ in a name.
+
+ If RADIUS is used as a AAA transport, the acceptor MUST send the
+ acceptor name in these attribute types. That is, the acceptor
+ decomposes its name and sends any non-empty portion as a RADIUS
+ attribute. With the exception of the service-specifics portion of
+ the name, the backslash escaping mechanism is not used in RADIUS
+ attributes; backslash has no special meaning. In the service-
+ specifics portion, a literal "/" separates components. In this one
+ attribute, "\/" indicates a slash character that does not separate
+ components and "\\" indicates a literal backslash character.
+
+ The initiator MUST require that the EAP method in use support channel
+ binding and MUST send the acceptor name as part of the channel
+ binding data. The client MUST NOT indicate mutual authentication in
+ the result of GSS_Init_sec_context unless all name elements that the
+ client supplied are in a successful channel binding response. For
+ example, if the client supplied a hostname in channel binding data,
+ the hostname MUST be in a successful channel binding response.
+
+ If an empty target name is supplied to GSS_Init_sec_context, the
+ initiator MUST fail context establishment unless the acceptor
+ supplies the acceptor name response (Section 5.4.3). If a null
+ target name is supplied, the initiator MUST use this response to
+ populate EAP channel bindings.
+
+3.5. Proxy Verification of Acceptor Name
+
+ Proxies may play a role in verification of the acceptor identity.
+ For example, a AAA proxy near the acceptor may be in a position to
+ verify the acceptor hostname, while the EAP server is likely to be
+ too distant to reliably verify this on its own.
+
+ The EAP server or some proxy trusted by the EAP server is likely to
+ be in a position to verify the acceptor realm. In effect, this proxy
+ is confirming that the right AAA credential is used for the claimed
+ realm and thus that the acceptor is in the organization it claims to
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 11]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ be part of. This proxy is also typically trusted by the EAP server
+ to make sure that the hostname claimed by the acceptor is a
+ reasonable hostname for the realm of the acceptor.
+
+ A proxy close to the EAP server is unlikely to be in a position to
+ confirm that the acceptor is claiming the correct hostname. Instead,
+ this is typically delegated to a proxy near the acceptor. That proxy
+ is typically expected to verify the acceptor hostname and to verify
+ the appropriate AAA credential for that host is used. Such a proxy
+ may insert the acceptor realm if it is absent, permitting realm
+ configuration to be at the proxy boundary rather than on acceptors.
+
+ Ultimately, specific proxy behavior is a matter for deployment. The
+ EAP server MUST assure that the appropriate validation has been done
+ before including acceptor name attributes in a successful channel
+ binding response. If the acceptor service is included, the EAP
+ server asserts that the service is plausible for the acceptor. If
+ the acceptor hostname is included, the EAP server asserts that the
+ acceptor hostname is verified. If the realm is included the EAP
+ server asserts that the realm has been verified, and if the hostname
+ was also included, that the realm and hostname are consistent. Part
+ of this verification MAY be delegated to proxies, but the EAP server
+ configuration MUST guarantee that the combination of proxies meets
+ these requirements. Typically, such delegation will involve business
+ or operational measures such as cross-organizational agreements as
+ well as technical measures.
+
+ It is likely that future technical work will be needed to communicate
+ what verification has been done by proxies along the path. Such
+ technical measures will not release the EAP server from its
+ responsibility to decide whether proxies on the path should be
+ trusted to perform checks delegated to them. However, technical
+ measures could prevent misconfigurations and help to support diverse
+ environments.
+
+4. Selection of EAP Method
+
+ EAP does not provide a facility for an EAP server to advertise what
+ methods are available to a peer. Instead, a server starts with its
+ preferred method selection. If the peer does not accept that method,
+ the peer sends a NAK response containing the list of methods
+ supported by the client.
+
+ Providing multiple facilities to negotiate which security mechanism
+ to use is undesirable. Section 7.3 of [RFC4462]describes the problem
+ referencing the Secure Shell (SSH) Protocol key exchange negotiation
+ and the SPNEGO GSS-API mechanism. If a client preferred an EAP
+ method A, a non-EAP authentication mechanism B, and then an EAP
+
+
+
+Hartman & Howlett Standards Track [Page 12]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ method C, then the client would have to commit to using EAP before
+ learning whether A is actually supported. Such a client might end up
+ using C when B is available.
+
+ The standard solution to this problem is to perform all the
+ negotiation at one layer. In this case, rather than defining a
+ single GSS-API mechanism, a family of mechanisms should be defined.
+ Each mechanism corresponds to an EAP method. The EAP method type
+ should be part of the GSS-API OID. Then, a GSS-API rather than EAP
+ facility can be used for negotiation.
+
+ Unfortunately, using a family of mechanisms has a number of problems.
+ First, GSS-API assumes that both the initiator and acceptor know the
+ entire set of mechanisms that are available. Some negotiation
+ mechanisms are driven by the client; others are driven by the server.
+ With EAP GSS-API, the acceptor does not know what methods the EAP
+ server implements. The EAP server that is used depends on the
+ identity of the client. The best solution so far is to accept the
+ disadvantages of multi-layer negotiation and commit to using EAP GSS-
+ API before a specific EAP method. This has two main disadvantages.
+ First, authentication may fail when other methods might allow
+ authentication to succeed. Second, a non-optimal security mechanism
+ may be chosen.
+
+5. Context Tokens
+
+ All context establishment tokens emitted by the EAP mechanism SHALL
+ have the framing described in Section 3.1 of [RFC2743], as
+ illustrated by the following pseudo-ASN.1 structures:
+
+ GSS-API DEFINITIONS ::=
+ BEGIN
+
+ MechType ::= OBJECT IDENTIFIER
+ -- representing EAP mechanism
+ GSSAPI-Token ::=
+ -- option indication (delegation, etc.) indicated within
+ -- mechanism-specific token
+ [APPLICATION 0] IMPLICIT SEQUENCE {
+ thisMech MechType,
+ innerToken ANY DEFINED BY thisMech
+ -- contents mechanism-specific
+ -- ASN.1 structure not required
+ }
+ END
+
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 13]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ The innerToken field starts with a 16-bit network byte order token
+ type identifier. The remainder of the innerToken field is a set of
+ type-length-value subtokens. The following figure describes the
+ structure of the inner token:
+
+ +----------------+---------------------------+
+ | Octet Position | Description |
+ +----------------+---------------------------+
+ | 0..1 | token ID |
+ | | |
+ | 2..5 | first subtoken type |
+ | | |
+ | 6..9 | length of first subtoken |
+ | | |
+ | 10..10+n-1 | first subtoken body |
+ | | |
+ | 10+n..10+n+3 | second subtoken type |
+ +----------------+---------------------------+
+
+ Structure of Inner Token
+
+ The inner token continues with length, second subtoken body, and so
+ forth. If a subtoken type is present, its length and body MUST be
+ present.
+
+ The length is a four-octet length of the subtoken body in network
+ byte order. The length does not include the length of the type field
+ or the length field; the length only covers the body.
+
+ Tokens from the initiator to acceptor use an inner token type with ID
+ 06 01; tokens from acceptor to initiator use an inner token type with
+ ID 06 02. These token types are registered in the registry of RFC
+ 4121 token types; see Section 7.2.
+
+ See Section 5.7 for the encoding of a complete token. The following
+ sections discuss how mechanism OIDs are chosen and the state machine
+ that defines what subtokens are permitted at each point in the
+ context establishment process.
+
+5.1. Mechanisms and Encryption Types
+
+ This mechanism family uses the security services of the Kerberos
+ cryptographic framework [RFC3961]. The root of the OID ARC for
+ mechanisms described in this document is 1.3.6.1.5.5.15.1.1; a
+ Kerberos encryption type number [RFC3961] is appended to that root
+ OID to form a mechanism OID. As such, a particular encryption type
+ needs to be chosen. By convention, there is a single object
+ identifier arc for the EAP family of GSS-API mechanisms. A specific
+
+
+
+Hartman & Howlett Standards Track [Page 14]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ mechanism is chosen by adding the numeric Kerberos encryption type
+ number to the root of this arc. However, in order to register the
+ SASL name, the specific usage with a given encryption type needs to
+ be registered. This document defines the EAP-AES128 GSS-API
+ mechanism.
+
+5.2. Processing Received Tokens
+
+ Whenever a context token is received, the receiver performs the
+ following checks. First, the receiver confirms the object identifier
+ is that of the mechanism being used. The receiver confirms that the
+ token type corresponds to the role of the peer: acceptors will only
+ process initiator tokens and initiators will only process acceptor
+ tokens.
+
+ Implementations of this mechanism maintain a state machine for the
+ context establishment process. Both the initiator and acceptor start
+ out in the initial state; see Section 5.4 for a description of this
+ state. Associated with each state are a set of subtoken types that
+ are processed in that state and rules for processing these subtoken
+ types. The receiver examines the subtokens in order, processing any
+ that are appropriate for the current state. Unknown subtokens or
+ subtokens that are not expected in the current state are ignored if
+ their critical bit (see below) is clear.
+
+ A state may have a set of required subtoken types. If a subtoken
+ type is required by the current state but no subtoken of that type is
+ present, then the context establishment MUST fail.
+
+ The most significant bit (0x80000000) in a subtoken type is the
+ critical bit. If a subtoken with this bit set in the type is
+ received, the receiver MUST fail context establishment unless the
+ subtoken is understood and processed for the current state.
+
+ The subtoken type MUST be unique within a given token.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 15]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+5.3. Error Subtokens
+
+ The acceptor may always end the exchange by generating an error
+ subtoken. The error subtoken has the following format:
+
+ +--------+----------------------------------------------------------+
+ | Pos | Description |
+ +--------+----------------------------------------------------------+
+ | 0..3 | 0x80 00 00 01 |
+ | | |
+ | 4..7 | length of error token |
+ | | |
+ | 8..11 | major status from RFC 2744 as 32-bit network byte order |
+ | | |
+ | 12..15 | GSS-EAP error code as 32-bit network byte order; see |
+ | | Section 7.6 |
+ +--------+----------------------------------------------------------+
+
+ Initiators MUST ignore octets beyond the GSS-EAP error code for
+ future extensibility. As indicated, the error token is always marked
+ critical.
+
+5.4. Initial State
+
+ Both the acceptor and initiator start the context establishment
+ process in the initial state.
+
+ The initiator sends a token to the acceptor. It MAY be empty; no
+ subtokens are required in this state. Alternatively, the initiator
+ MAY include a vendor ID subtoken or an acceptor name request
+ subtoken.
+
+ The acceptor responds to this message. It MAY include an acceptor
+ name response subtoken. It MUST include a first EAP request; this is
+ an EAP request/identity message (see Section 5.5.1 for the format of
+ this subtoken).
+
+ The initiator and acceptor then transition to authenticate state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 16]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+5.4.1. Vendor Subtoken
+
+ The vendor ID subtoken has type 0x0000000B and the following
+ structure:
+
+ +-------------+------------------------+
+ | Pos | Description |
+ +-------------+------------------------+
+ | 0..3 | 0x0000000B |
+ | | |
+ | 4..7 | length of vendor token |
+ | | |
+ | 8..8+length | Vendor ID string |
+ +-------------+------------------------+
+
+ The vendor ID string is an UTF-8 string describing the vendor of this
+ implementation. This string is unstructured and for debugging
+ purposes only.
+
+5.4.2. Acceptor Name Request
+
+ The acceptor name request token is sent from the initiator to the
+ acceptor indicating that the initiator wishes a particular acceptor
+ name. This is similar to Transport Layer Security (TLS) Server Name
+ Indication [RFC6066] that permits a client to indicate which one of a
+ number of virtual services to contact. The structure is as follows:
+
+ +------+------------------------------+
+ | Pos | Description |
+ +------+------------------------------+
+ | 0..3 | 0x00000002 |
+ | | |
+ | 4..7 | length of subtoken |
+ | | |
+ | 8..n | string form of acceptor name |
+ +------+------------------------------+
+
+ It is likely that channel binding and thus authentication will fail
+ if the acceptor does not choose a name that is a superset of this
+ name. That is, if a hostname is sent, the acceptor needs to be
+ willing to accept this hostname.
+
+
+
+
+
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 17]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+5.4.3. Acceptor Name Response
+
+ The acceptor name response subtoken indicates what acceptor name is
+ used. This is useful, for example, if the initiator supplied no
+ target name to the context initialization. This allows the initiator
+ to learn the acceptor name. EAP channel bindings will provide
+ confirmation that the acceptor is accurately naming itself.
+
+ This token is sent from the acceptor to initiator. In the Initial
+ state, this token would typically be sent if the acceptor name
+ request is absent, because if the initiator already sent an acceptor
+ name, then the initiator knows what acceptor it wishes to contact.
+ This subtoken is also sent in Extensions state Section 5.6, so the
+ initiator can protect against a man-in-the-middle modifying the
+ acceptor name request subtoken.
+
+ +------+------------------------------+
+ | Pos | Description |
+ +------+------------------------------+
+ | 0..3 | 0x00000003 |
+ | | |
+ | 4..7 | length of subtoken |
+ | | |
+ | 8..n | string form of acceptor name |
+ +------+------------------------------+
+
+5.5. Authenticate State
+
+ In this state, the acceptor sends EAP requests to the initiator and
+ the initiator generates EAP responses. The goal of the state is to
+ perform a successful EAP authentication. Since the acceptor sends an
+ identity request at the end of the initial state, the first half-
+ round-trip in this state is a response to that request from the
+ initiator.
+
+ The EAP conversation can end in a number of ways:
+
+ o If the EAP state machine generates an EAP Success message, then
+ the EAP authenticator believes the authentication is successful.
+ The acceptor MUST confirm that a key has been derived
+ (Section 7.10 of [RFC3748]). The acceptor MUST confirm that this
+ success indication is consistent with any protected result
+ indication for combined authenticators and with AAA indication of
+ success for pass-through authenticators. If any of these checks
+ fail, the acceptor MUST send an error subtoken and fail the
+ context establishment. If these checks succeed, the acceptor
+ sends the Success message using the EAP Request subtoken type and
+ transitions to Extensions state. If the initiator receives an EAP
+
+
+
+Hartman & Howlett Standards Track [Page 18]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ Success message, it confirms that a key has been derived and that
+ the EAP Success is consistent with any protected result
+ indication. If so, it transitions to Extensions state.
+ Otherwise, it returns an error to the caller of
+ GSS_Init_sec_context without producing an output token.
+
+ o If the acceptor receives an EAP failure, then the acceptor sends
+ this in the EAP Request subtoken type. If the initiator receives
+ an EAP Failure, it returns GSS failure.
+
+ o If there is some other error, the acceptor MAY return an error
+ subtoken.
+
+5.5.1. EAP Request Subtoken
+
+ The EAP Request subtoken is sent from the acceptor to the initiator.
+ This subtoken is always critical and is REQUIRED in the
+ authentication state.
+
+ +-------------+-----------------------+
+ | Pos | Description |
+ +-------------+-----------------------+
+ | 0..3 | 0x80000005 |
+ | | |
+ | 4..7 | length of EAP message |
+ | | |
+ | 8..8+length | EAP message |
+ +-------------+-----------------------+
+
+5.5.2. EAP Response Subtoken
+
+ This subtoken is REQUIRED in authentication state messages from the
+ initiator to the acceptor. It is always critical.
+
+ +-------------+-----------------------+
+ | Pos | Description |
+ +-------------+-----------------------+
+ | 0..3 | 0x80000004 |
+ | | |
+ | 4..7 | length of EAP message |
+ | | |
+ | 8..8+length | EAP message |
+ +-------------+-----------------------+
+
+
+
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 19]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+5.6. Extensions State
+
+ After EAP Success, the initiator sends a token to the acceptor
+ including additional subtokens that negotiate optional features or
+ provide GSS-API channel binding (see Section 6.1). The acceptor then
+ responds with a token to the initiator. When the acceptor produces
+ its final token, it returns GSS_S_COMPLETE; when the initiator
+ consumes this token, it returns GSS_S_COMPLETE if no errors are
+ detected.
+
+ The acceptor SHOULD send an acceptor name response (Section 5.4.3) so
+ that the initiator can get a copy of the acceptor name protected by
+ the Message Integrity Check (MIC) subtoken.
+
+ Both the initiator and acceptor MUST include and verify a MIC
+ subtoken to protect the extensions exchange.
+
+5.6.1. Flags Subtoken
+
+ This subtoken is sent to convey initiator flags to the acceptor. The
+ flags are sent as a 32-bit integer in network byte order. The only
+ flag defined so far is GSS_C_MUTUAL_FLAG, indicating that the
+ initiator successfully performed mutual authentication of the
+ acceptor. This flag is communicated to the acceptor because some
+ protocols [RFC4462] require the acceptor to know whether the
+ initiator has confirmed its identity. This flag has the value 0x2 to
+ be consistent with RFC 2744.
+
+ +-------+-----------------------+
+ | Pos | Description |
+ +-------+-----------------------+
+ | 0..3 | 0x0000000C |
+ | | |
+ | 4..7 | length of flags token |
+ | | |
+ | 8..11 | flags |
+ +-------+-----------------------+
+
+ Initiators MUST send 4 octets of flags. Acceptors MUST ignore flag
+ octets beyond the first 4 and MUST ignore flag bits other than
+ GSS_C_MUTUAL_FLAG. Initiators MUST send undefined flag bits as zero.
+
+5.6.2. GSS Channel Bindings Subtoken
+
+ This subtoken is always critical when sent. It is sent from the
+ initiator to the acceptor. The contents of this token are an RFC
+ 3961 get_mic token of the application data from the GSS channel
+ bindings structure passed into the context establishment call.
+
+
+
+Hartman & Howlett Standards Track [Page 20]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ +-------------+-----------------------------------------------+
+ | Pos | Description |
+ +-------------+-----------------------------------------------+
+ | 0..3 | 0x80000006 |
+ | | |
+ | 4..7 | length of token |
+ | | |
+ | 8..8+length | get_mic of channel binding application data |
+ +-------------+-----------------------------------------------+
+
+ Again, only the application data is sent in the channel binding. Any
+ initiator and acceptor addresses passed by an application into
+ context establishment calls are ignored and not sent over the wire.
+ The checksum type of the get_mic token SHOULD be the mandatory-to-
+ implement checksum type of the Context Root Key (CRK). The key to
+ use is the CRK and the key usage is 60 (KEY_USAGE_GSSEAP_CHBIND_MIC).
+ An acceptor MAY accept any MIC in the channel bindings subtoken if
+ the channel bindings input to GSS_Accept_sec_context is not provided.
+ If the channel binding input to GSS_Accept_sec_context is provided,
+ the acceptor MUST return failure if the channel binding MIC in a
+ received channel binding subtoken fails to verify.
+
+ The initiator MUST send this token if channel bindings including
+ application data are passed into GSS_Init_sec_context and MUST NOT
+ send this token otherwise.
+
+5.6.3. MIC Subtoken
+
+ This subtoken MUST be the last subtoken in the tokens sent in
+ Extensions state. This subtoken is sent both by the initiator and
+ acceptor.
+
+ +-------------+--------------------------------------------------+
+ | Pos | Description |
+ +-------------+--------------------------------------------------+
+ | 0..3 | 0x8000000D for initiator 0x8000000E for acceptor |
+ | | |
+ | 4..7 | length of RFC 3961 MIC token |
+ | | |
+ | 8..8+length | RFC 3961 result of get_mic |
+ +-------------+--------------------------------------------------+
+
+ As with any call to get_mic, a token is produced as described in RFC
+ 3961 using the CRK (Section 6) as the key and the mandatory checksum
+ type for the encryption type of the CRK as the checksum type. The
+ key usage is 61 (KEY_USAGE_GSSEAP_ACCTOKEN_MIC) for the subtoken from
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 21]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ the acceptor to the initiator and 62 (KEY_USAGE_GSSEAP_INITTOKEN_MIC)
+ for the subtoken from the initiator to the acceptor. The input is as
+ follows:
+
+ 1. The DER-encoded object identifier of the mechanism in use; this
+ value starts with 0x06 (the tag for object identifier). When
+ encoded in an RFC 2743 context token, the object identifier is
+ preceded by the tag and length for [Application 0] SEQUENCE.
+ This tag and the length of the overall token is not included;
+ only the tag, length, and value of the object identifier itself.
+
+ 2. A 16-bit token type in network byte order of the RFC 4121 token
+ identifier (0x0601 for initiator, 0x0602 for acceptor).
+
+ 3. For each subtoken, other than the MIC subtoken itself, the order
+ the subtokens appear in the token is as follows:
+
+ 4.
+
+ 1. A four-octet subtoken type in network byte order
+
+ 2. A four-byte length in network byte order
+
+ 3. Length octets of value from that subtoken
+
+5.7. Example Token
+
+ +----+------+----+------+-----+-------------------------+
+ | 60 | 23 | 06 | 09 | 2b | 06 01 05 05 0f 01 01 11 |
+ +----+------+----+------+-----+-------------------------+
+ |App0|Token |OID |OID | 1 3 | 6 1 5 5 15 1 1 17 |
+ |Tag |length|Tag |length| Mechanism object ID |
+ +----+------+----+------+-------------------------------+
+
+ +----------+-------------+-------------+
+ | 06 01 | 00 00 00 02 | 00 00 00 0e |
+ +----------+-------------|-------------|
+ |Initiator | Acceptor | Length |
+ |context | name | (14 octets) |
+ |token ID | request | |
+ +----------+-------------+-------------+
+
+ +-------------------------------------------+
+ | 68 6f 73 74 2f 6c 6f 63 61 6c 68 6f 73 74 |
+ +-------------------------------------------+
+ | String form of acceptor name |
+ | "host/localhost" |
+ +-------------------------------------------+
+
+
+
+Hartman & Howlett Standards Track [Page 22]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ Example Initiator Token
+
+5.8. Context Options
+
+ GSS-API provides a number of optional per-context services requested
+ by flags on the call to GSS_Init_sec_context and indicated as outputs
+ from both GSS_Init_sec_context and GSS_Accept_sec_context. This
+ section describes how these services are handled. Which services the
+ client selects in the call to GSS_Init_sec_context controls what EAP
+ methods MAY be used by the client. Section 7.2 of RFC 3748 describes
+ a set of security claims for EAP. As described below, the selected
+ GSS options place requirements on security claims that MUST be met.
+
+ This GSS mechanism MUST only be used with EAP methods that provide
+ dictionary-attack resistance. Typically, dictionary-attack
+ resistance is obtained by using an EAP tunnel method to tunnel an
+ inner method in TLS.
+
+ The EAP method MUST support key derivation. Integrity,
+ confidentiality, sequencing, and replay detection MUST be indicated
+ in the output of GSS_Init_sec_context and GSS_Accept_sec_context
+ regardless of which services are requested.
+
+ The PROT_READY service defined in Section 1.2.7 of [RFC2743] is never
+ available with this mechanism. Implementations MUST NOT offer this
+ flag or permit per-message security services to be used before
+ context establishment.
+
+ The EAP method MUST support mutual authentication and channel
+ binding. See Section 3.4 for details on what is required for
+ successful mutual authentication. Regardless of whether mutual
+ authentication is requested, the implementation MUST include channel
+ bindings in the EAP authentication. If mutual authentication is
+ requested and successful mutual authentication takes place as defined
+ in Section 3.4, the initiator MUST send a flags subtoken
+ Section 5.6.1 in Extensions state.
+
+6. Acceptor Services
+
+ The context establishment process may be passed through to an EAP
+ server via a backend authentication protocol. However, after the EAP
+ authentication succeeds, security services are provided directly by
+ the acceptor.
+
+ This mechanism uses an RFC 3961 cryptographic key called the Context
+ Root Key (CRK). The CRK is derived from the GMSK (GSS-API Master
+ Session Key). The GMSK is the result of the random-to-key [RFC3961]
+ operation of the encryption type of this mechanism consuming the
+
+
+
+Hartman & Howlett Standards Track [Page 23]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ appropriate number of bits from the EAP MSK. For example, for
+ aes128-cts-hmac-sha1-96, the random-to-key operation consumes 16
+ octets of key material; thus, the first 16 bytes of the MSK are input
+ to random-to-key to form the GMSK. If the MSK is too short,
+ authentication MUST fail.
+
+ In the following, pseudorandom is the RFC 3961 pseudorandom operation
+ for the encryption type of the GMSK and random-to-key is the RFC 3961
+ random-to-key operation for the enctype of the mechanism. The
+ truncate function takes the initial l bits of its input. The goal in
+ constructing a CRK is to call the pseudorandom function enough times
+ to produce the right number of bits of output and discard any excess
+ bits of output.
+
+ The CRK is derived from the GMSK using the following procedure:
+
+ Tn = pseudorandom(GMSK, n || "rfc4121-gss-eap")
+ CRK = random-to-key(truncate(L, T0 || T1 || .. || Tn))
+ L = random-to-key input size
+
+ Where n is a 32-bit integer in network byte order starting at 0 and
+ incremented to each call to the pseudo_random operation.
+
+6.1. GSS-API Channel Binding
+
+ GSS-API channel binding [RFC5554] is a protected facility for
+ exchanging a cryptographic name for an enclosing channel between the
+ initiator and acceptor. The initiator sends channel binding data and
+ the acceptor confirms that channel binding data has been checked.
+
+ The acceptor SHOULD accept any channel binding provided by the
+ initiator if null channel bindings are passed into
+ gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559]
+ depend on this behavior of some Kerberos implementations.
+
+ As discussed, the GSS channel bindings subtoken is sent in the
+ Extensions state.
+
+6.2. Per-Message Security
+
+ The per-message tokens of Section 4 of RFC 4121 are used. The CRK
+ SHALL be treated as the initiator sub-session key, the acceptor sub-
+ session key and the ticket session key.
+
+6.3. Pseudorandom Function
+
+ The pseudorandom function defined in [RFC4402] is used to provide
+ GSS_Pseudo_Random functionality to applications.
+
+
+
+Hartman & Howlett Standards Track [Page 24]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+7. IANA Considerations
+
+ This specification creates a number of IANA registries.
+
+7.1. OID Registry
+
+ IANA has created a registry of ABFAB object identifiers titled
+ "Object Identifiers for Application Bridging for Federated Access".
+ The initial contents of the registry are specified below. The
+ registration policy is IETF Review or IESG Approval [RFC5226]. Early
+ allocation is permitted. IANA has updated the reference for the root
+ of this OID delegation to point to the newly created registry.
+
+ Decimal Name Description References
+ ------- ---- ---------------------------------- ----------
+ 0 Reserved Reserved RFC 7055
+ 1 mechanisms A sub-arc containing ABFAB RFC 7055
+ mechanisms
+ 2 nametypes A sub-arc containing ABFAB RFC 7055
+ GSS-API Name Types
+
+ Prefix:
+ iso.org.dod.internet.security.mechanisms.abfab
+ (1.3.6.1.5.5.15)
+
+ NOTE: the following mechanisms registry is the root of the OID for
+ the mechanism in question. As discussed in Section 5.1, a Kerberos
+ encryption type number [RFC3961] is appended to the mechanism version
+ OID below to form the OID of a specific mechanism.
+
+ Prefix:
+ iso.org.dod.internet.security.mechanisms.abfab.mechanisms
+ (1.3.6.1.5.5.15.1)
+
+ Decimal Name Description References
+ ------- ---- ------------------------------- ----------
+ 0 Reserved Reserved RFC 7055
+ 1 gss-eap-v1 The GSS-EAP mechanism RFC 7055
+
+ Prefix:
+ iso.org.dod.internet.security.mechanisms.abfab.nametypes
+ (1.3.6.1.5.5.15.2)
+
+ Decimal Name Description References
+ ------- ---- --------------------- ----------
+ 0 Reserved Reserved RFC 7055
+ 1 GSS_EAP_NT_EAP_NAME RFC 7055, Section 3.1
+
+
+
+
+Hartman & Howlett Standards Track [Page 25]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+7.2. RFC 4121 Token Identifiers
+
+ In the top-level registry titled "Kerberos V GSS-API Mechanism
+ Parameters", a subregistry called "Kerberos GSS-API Token Type
+ Identifiers" was created; the references for this subregistry are RFC
+ 4121 and this document. The allocation procedure is Expert Review
+ [RFC5226]. The Expert's primary job is to make sure that token type
+ identifiers are requested by an appropriate requester for the RFC
+ 4121 mechanism in which they will be used and that multiple values
+ are not allocated for the same purpose. For RFC 4121 and this
+ mechanism, the Expert is currently expected to make allocations for
+ token identifiers from documents in the IETF stream; effectively, for
+ these mechanisms, the Expert currently confirms the allocation meets
+ the requirements of the IETF Review process.
+
+ The ID field is a hexadecimal token identifier specified in network
+ byte order.
+
+ The initial registrations are as follows:
+
+ +-------+-------------------------------+---------------------------+
+ | ID | Description | Reference |
+ +-------+-------------------------------+---------------------------+
+ | 01 00 | KRB_AP_REQ | RFC 4121, Section 4.1 |
+ | | | |
+ | 02 00 | KRB_AP_REP | RFC 4121, Section 4.1 |
+ | | | |
+ | 03 00 | KRB_ERROR | RFC 4121, Section 4.1 |
+ | | | |
+ | 04 04 | MIC tokens | RFC 4121, Section 4.2.6.1 |
+ | | | |
+ | 05 04 | wrap tokens | RFC 4121, Section 4.2.6.2 |
+ | | | |
+ | 06 01 | GSS-EAP initiator context | RFC 7055, Section 5 |
+ | | token | |
+ | | | |
+ | 06 02 | GSS EAP acceptor context | RFC 7055, Section 5 |
+ | | token | |
+ +-------+-------------------------------+---------------------------+
+
+7.3. GSS-EAP Subtoken Types
+
+ This document creates a top-level registry called "The Extensible
+ Authentication Protocol Mechanism for the Generic Security Service
+ Application Programming Interface (GSS-EAP) Parameters". In any
+ short form of that name, including any URI for this registry, it is
+ important that the string GSS come before the string EAP; this will
+
+
+
+
+Hartman & Howlett Standards Track [Page 26]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ help to distinguish registries if EAP methods for performing GSS-API
+ authentication are ever defined.
+
+ In this registry is a subregistry of subtoken types. Identifiers are
+ 32-bit integers; the upper bit (0x80000000) is reserved as a critical
+ flag and should not be indicated in the registration. Assignments of
+ GSS-EAP subtoken types are made by Expert Review [RFC5226]. The
+ Expert is expected to require a public specification of the subtoken
+ similar in detail to registrations given in this document. The
+ security of GSS-EAP depends on making sure that subtoken information
+ has adequate protection and that the overall mechanism continues to
+ be secure. Examining the security and architectural consistency of
+ the proposed registration is the primary responsibility of the
+ Expert.
+
+ +------------+--------------------------+---------------+
+ | Type | Description | Reference |
+ +------------+--------------------------+---------------+
+ | 0x00000001 | Error | Section 5.3 |
+ | | | |
+ | 0x0000000B | Vendor | Section 5.4.1 |
+ | | | |
+ | 0x00000002 | Acceptor name request | Section 5.4.2 |
+ | | | |
+ | 0x00000003 | Acceptor name response | Section 5.4.3 |
+ | | | |
+ | 0x00000005 | EAP request | Section 5.5.1 |
+ | | | |
+ | 0x00000004 | EAP response | Section 5.5.2 |
+ | | | |
+ | 0x0000000C | Flags | Section 5.6.1 |
+ | | | |
+ | 0x00000006 | GSS-API channel bindings | Section 5.6.2 |
+ | | | |
+ | 0x0000000D | Initiator MIC | Section 5.6.3 |
+ | | | |
+ | 0x0000000E | Acceptor MIC | Section 5.6.3 |
+ +------------+--------------------------+---------------+
+
+7.4. RADIUS Attribute Assignments
+
+ The following RADIUS attribute type values [RFC3575] are assigned.
+ The allocation instructions in Section 10.3 of [RFC6929] have been
+ followed.
+
+
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 27]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ +--------------------------------+-------+--------------------------+
+ | Description | Value | More Information |
+ +--------------------------------+-------+--------------------------+
+ | GSS-Acceptor-Service-Name | 164 | user-or-service portion |
+ | | | of name |
+ | | | |
+ | GSS-Acceptor-Host-Name | 165 | host portion of name |
+ | | | |
+ | GSS-Acceptor-Service-Specifics | 166 | service-specifics |
+ | | | portion of name |
+ | | | |
+ | GSS-Acceptor-Realm-Name | 167 | Realm portion of name |
+ +--------------------------------+-------+--------------------------+
+
+7.5. Registration of the EAP-AES128 SASL Mechanisms
+
+ Subject: Registration of SASL mechanisms EAP-AES128 and
+ EAP-AES128-PLUS
+
+ SASL mechanism names: EAP-AES128 and EAP-AES128-PLUS
+
+ Security considerations: See RFC 5801 and RFC 7055
+
+ Published specification (recommended): RFC 7055
+
+ Person & email address to contact for further information:
+ Abfab Working Group, abfab@ietf.org
+
+ Intended usage: common
+
+ Owner/Change controller: iesg@ietf.org
+
+ Note: This mechanism describes the GSS-EAP mechanism used with the
+ aes128-cts-hmac-sha1-96 enctype. The GSS-API OID for this
+ mechanism is 1.3.6.1.5.5.15.1.1.17.
+
+ As described in RFC 5801, a PLUS variant of this mechanism is also
+ required.
+
+7.6. GSS-EAP Errors
+
+ A new subregistry is created in the GSS-EAP parameters registry
+ titled "GSS-EAP Error Codes". The error codes in this registry are
+ unsigned 32-bit numbers. Values less than or equal to 127 are
+ assigned by Standards Action [RFC5226]. Values 128 through 255 are
+ assigned with the Specification Required assignment policy [RFC5226].
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 28]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ Values greater than 255 are reserved; updates to registration policy
+ may make these values available for assignment and implementations
+ MUST be prepared to receive them.
+
+ This table provides the initial contents of the registry.
+
+ +-------+------------------------------------------------+
+ | Value | Description |
+ +-------+------------------------------------------------+
+ | 0 | Reserved |
+ | | |
+ | 1 | Buffer is incorrect size |
+ | | |
+ | 2 | Incorrect mechanism OID |
+ | | |
+ | 3 | Token is corrupted |
+ | | |
+ | 4 | Token is truncated |
+ | | |
+ | 5 | Packet received by direction that sent it |
+ | | |
+ | 6 | Incorrect token type identifier |
+ | | |
+ | 7 | Unhandled critical subtoken received |
+ | | |
+ | 8 | Missing required subtoken |
+ | | |
+ | 9 | Duplicate subtoken type |
+ | | |
+ | 10 | Received unexpected subtoken for current state |
+ | | |
+ | 11 | EAP did not produce a key |
+ | | |
+ | 12 | EAP key too short |
+ | | |
+ | 13 | Authentication rejected |
+ | | |
+ | 14 | AAA returned an unexpected message type |
+ | | |
+ | 15 | AAA response did not include EAP request |
+ | | |
+ | 16 | Generic AAA failure |
+ +-------+------------------------------------------------+
+
+
+
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 29]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+7.7. GSS-EAP Context Flags
+
+ A new subregistry is created in the GSS-EAP parameters registry.
+ This registry holds registrations of flag bits sent in the flags
+ subtoken (Section 5.6.1). There are 32 flag bits available for
+ registration represented as hexadecimal numbers from the most
+ significant bit 0x80000000 to the least significant bit 0x1. The
+ registration policy for this registry is IETF Review or, in
+ exceptional cases, IESG Approval. The following table indicates
+ initial registrations; all other values are available for assignment.
+
+ +------+-------------------+---------------+
+ | Flag | Name | Reference |
+ +------+-------------------+---------------+
+ | 0x2 | GSS_C_MUTUAL_FLAG | Section 5.6.1 |
+ +------+-------------------+---------------+
+
+8. Security Considerations
+
+ RFC 3748 discusses security issues surrounding EAP. RFC 5247
+ discusses the security and requirements surrounding key management
+ that leverages the AAA infrastructure. These documents are critical
+ to the security analysis of this mechanism.
+
+ RFC 2743 discusses generic security considerations for the GSS-API.
+ RFC 4121 discusses security issues surrounding the specific per-
+ message services used in this mechanism.
+
+ As discussed in Section 4, this mechanism may introduce multiple
+ layers of security negotiation into application protocols. Multiple
+ layer negotiations are vulnerable to a bid-down attack when a
+ mechanism negotiated at the outer layer is preferred to some but not
+ all mechanisms negotiated at the inner layer; see Section 7.3 of
+ [RFC4462] for an example. One possible approach to mitigate this
+ attack is to construct security policy such that the preference for
+ all mechanisms negotiated in the inner layer falls between
+ preferences for two outer-layer mechanisms or falls at one end of the
+ overall ranked preferences including both the inner and outer layer.
+ Another approach is to only use this mechanism when it has
+ specifically been selected for a given service. The second approach
+ is likely to be common in practice because one common deployment will
+ involve an EAP supplicant interacting with a user to select a given
+ identity. Only when an identity is successfully chosen by the user
+ will this mechanism be attempted.
+
+ EAP channel binding is used to give the GSS-API initiator confidence
+ in the identity of the GSS-API acceptor. Thus, the security of this
+ mechanism depends on the use and verification of EAP channel binding.
+
+
+
+Hartman & Howlett Standards Track [Page 30]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ Today, EAP channel binding is in very limited deployment. If EAP
+ channel binding is not used, then the system may be vulnerable to
+ phishing attacks where a user is diverted from one service to
+ another. If the EAP method in question supports mutual
+ authentication then users can only be diverted between servers that
+ are part of the same AAA infrastructure. For deployments where
+ membership in the AAA infrastructure is limited, this may serve as a
+ significant limitation on the value of phishing as an attack. For
+ other deployments, use of EAP channel binding is critical to avoid
+ phishing. These attacks are possible with EAP today although not
+ typically with common GSS-API mechanisms. For this reason,
+ implementations are required to implement and use EAP channel
+ binding; see Section 3 for details.
+
+ The security considerations of EAP channel binding [RFC6677] describe
+ the security properties of channel binding. Two attacks are worth
+ calling out here. First, when a tunneled EAP method is used, it is
+ critical that the channel binding be performed with an EAP server
+ trusted by the peer. With existing EAP methods, this typically
+ requires validating the certificate of the server tunnel endpoint
+ back to a trust anchor and confirming the name of the entity who is a
+ subject of that certificate. EAP methods may suffer from bid-down
+ attacks where an attacker can cause a peer to think that a particular
+ EAP server does not support channel binding. This does not directly
+ cause a problem because mutual authentication is only offered at the
+ GSS-API level when channel binding to the server's identity is
+ successful. However, when an EAP method is not vulnerable to these
+ bid-down attacks, additional protection is available. This mechanism
+ will benefit significantly from new strong EAP methods such as
+ [TEAP].
+
+ Every proxy in the AAA chain from the authenticator to the EAP server
+ needs to be trusted to help verify channel bindings and to protect
+ the integrity of key material. GSS-API applications may be built to
+ assume a trust model where the acceptor is directly responsible for
+ authentication. However, GSS-API is definitely used with trusted-
+ third-party mechanisms such as Kerberos.
+
+ RADIUS does provide a weak form of hop-by-hop confidentiality of key
+ material based on using MD5 as a stream cipher. Diameter can use TLS
+ or IPsec but has no mandatory-to-implement confidentiality mechanism.
+ Operationally, protecting key material as it is transported between
+ the Identity Provider (IdP) and Relying Party (RP) is critical to
+ per-message security and verification of GSS-API channel binding
+ [RFC5056]. Mechanisms such as RADIUS over TLS [RFC6614] provide
+ significantly better protection of key material than the base RADIUS
+ specification.
+
+
+
+
+Hartman & Howlett Standards Track [Page 31]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+9. Acknowledgements
+
+ Luke Howard, Jim Schaad, Alejandro Perez Mendez, Alexey Melnikov, and
+ Sujing Zhou provided valuable reviews of this document.
+
+ Rhys Smith provided the text for the OID registry section. Sam
+ Hartman's work on this document has been funded by JANET.
+
+10. References
+
+10.1. Normative References
+
+ [GSS-IANA] IANA, "GSS-API Service Name Registry",
+ <http://www.iana.org/assignments/gssapi-service-names>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2743] Linn, J., "Generic Security Service Application Program
+ Interface Version 2, Update 1", RFC 2743, January 2000.
+
+ [RFC2744] Wray, J., "Generic Security Service API Version 2 :
+ C-bindings", RFC 2744, January 2000.
+
+ [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
+ Authentication Dial In User Service)", RFC 3575, July
+ 2003.
+
+ [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+ Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
+ 3748, June 2004.
+
+ [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
+ Kerberos 5", RFC 3961, February 2005.
+
+ [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+ Version 5 Generic Security Service Application Program
+ Interface (GSS-API) Mechanism: Version 2", RFC 4121, July
+ 2005.
+
+ [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
+ Network Access Identifier", RFC 4282, December 2005.
+
+ [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API
+ Extension for the Generic Security Service Application
+ Program Interface (GSS-API)", RFC 4401, February 2006.
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 32]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the
+ Kerberos V Generic Security Service Application Program
+ Interface (GSS-API) Mechanism", RFC 4402, February 2006.
+
+ [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
+ Channels", RFC 5056, November 2007.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+ [RFC5554] Williams, N., "Clarifications and Extensions to the
+ Generic Security Service Application Program Interface
+ (GSS-API) for the Use of Channel Bindings", RFC 5554, May
+ 2009.
+
+ [RFC5891] Klensin, J., "Internationalized Domain Names in
+ Applications (IDNA): Protocol", RFC 5891, August 2010.
+
+ [RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding
+ Support for Extensible Authentication Protocol (EAP)
+ Methods", RFC 6677, July 2012.
+
+ [RFC7057] Winter, S. and J. Salowey, "Update to the Extensible
+ Authentication Protocol (EAP) Applicability Statement for
+ Application Bridging for Federated Access Beyond Web
+ (ABFAB)", RFC 7057, December 2013.
+
+10.2. Informative References
+
+ [ABFAB-ARCH]
+ Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
+ Schaad, "Application Bridging for Federated Access Beyond
+ Web (ABFAB) Architecture", Work in Progress, July 2013.
+
+ [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
+ 1964, June 1996.
+
+ [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
+ Dial In User Service) Support For Extensible
+ Authentication Protocol (EAP)", RFC 3579, September 2003.
+
+ [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
+ Authentication Protocol (EAP) Application", RFC 4072,
+ August 2005.
+
+
+
+Hartman & Howlett Standards Track [Page 33]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+ [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
+ Simple and Protected Generic Security Service Application
+ Program Interface (GSS-API) Negotiation Mechanism", RFC
+ 4178, October 2005.
+
+ [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
+ Security Layer (SASL)", RFC 4422, June 2006.
+
+ [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
+ "Generic Security Service Application Program Interface
+ (GSS-API) Authentication and Key Exchange for the Secure
+ Shell (SSH) Protocol", RFC 4462, May 2006.
+
+ [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
+ Kerberos and NTLM HTTP Authentication in Microsoft
+ Windows", RFC 4559, June 2006.
+
+ [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service
+ Application Program Interface (GSS-API)
+ Internationalization and Domain-Based Service Names and
+ Name Type", RFC 5178, May 2008.
+
+ [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
+ Authentication Protocol (EAP) Key Management Framework",
+ RFC 5247, August 2008.
+
+ [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
+ Extension Definitions", RFC 6066, January 2011.
+
+ [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
+ "Transport Layer Security (TLS) Encryption for RADIUS",
+ RFC 6614, May 2012.
+
+ [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
+ Service (RADIUS) Protocol Extensions", RFC 6929, April
+ 2013.
+
+ [TEAP] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
+ "Tunnel EAP Method (TEAP) Version 1", Work in Progress,
+ September 2013.
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 34]
+\f
+RFC 7055 EAP GSS-API December 2013
+
+
+Appendix A. Pre-publication RADIUS VSA
+
+ As described in Section 3.4, RADIUS attributes are used to carry the
+ acceptor name when this family of mechanisms is used with RADIUS.
+ Prior to the publication of this specification, a vendor-specific
+ RADIUS attribute was used. This non-normative appendix documents
+ that attribute as it may be seen from older implementations.
+
+ Prior to IANA assignment, GSS-EAP used a RADIUS vendor-specific
+ attribute for carrying the acceptor name. The Vendor-Specific
+ Attribute (VSA) with enterprise ID 25622 is formatted as a VSA
+ according to the recommendation in the RADIUS specification. The
+ following sub-attributes are defined:
+
+ +--------------------------------+-----------+----------------------+
+ | Name | Attribute | Description |
+ +--------------------------------+-----------+----------------------+
+ | GSS-Acceptor-Service-Name | 128 | user-or-service |
+ | | | portion of name |
+ | | | |
+ | GSS-Acceptor-Host-Name | 129 | host portion of name |
+ | | | |
+ | GSS-Acceptor-Service-Specifics | 130 | service-specifics |
+ | | | portion of name |
+ | | | |
+ | GSS-Acceptor-Realm-Name | 131 | Realm portion of |
+ | | | name |
+ +--------------------------------+-----------+----------------------+
+
+Authors' Addresses
+
+ Sam Hartman (editor)
+ Painless Security
+
+ EMail: hartmans-ietf@mit.edu
+
+
+ Josh Howlett
+ JANET(UK)
+
+ EMail: josh.howlett@ja.net
+
+
+
+
+
+
+
+
+
+
+Hartman & Howlett Standards Track [Page 35]
+\f
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) B. Aboba
+Request for Comments: 7268 Microsoft Corporation
+Updates: 3580, 4072 J. Malinen
+Category: Standards Track Independent
+ISSN: 2070-1721 P. Congdon
+ Tallac Networks
+ J. Salowey
+ Cisco Systems
+ M. Jones
+ Azuca Systems
+ July 2014
+
+
+ RADIUS Attributes for IEEE 802 Networks
+
+Abstract
+
+ RFC 3580 provides guidelines for the use of the Remote Authentication
+ Dial-In User Service (RADIUS) within IEEE 802 local area networks
+ (LANs). This document defines additional attributes for use within
+ IEEE 802 networks and clarifies the usage of the EAP-Key-Name
+ Attribute and the Called-Station-Id Attribute. This document updates
+ RFCs 3580 and 4072.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7268.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 1]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 2]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Terminology ................................................4
+ 1.2. Requirements Language ......................................4
+ 2. RADIUS Attributes ...............................................5
+ 2.1. Allowed-Called-Station-Id ..................................5
+ 2.2. EAP-Key-Name ...............................................6
+ 2.3. EAP-Peer-Id ................................................7
+ 2.4. EAP-Server-Id ..............................................8
+ 2.5. Mobility-Domain-Id .........................................9
+ 2.6. Preauth-Timeout ...........................................10
+ 2.7. Network-Id-Name ...........................................11
+ 2.8. EAPoL-Announcement ........................................12
+ 2.9. WLAN-HESSID ...............................................14
+ 2.10. WLAN-Venue-Info ..........................................14
+ 2.11. WLAN-Venue-Language ......................................16
+ 2.12. WLAN-Venue-Name ..........................................17
+ 2.13. WLAN-Reason-Code .........................................18
+ 2.14. WLAN-Pairwise-Cipher .....................................19
+ 2.15. WLAN-Group-Cipher ........................................20
+ 2.16. WLAN-AKM-Suite ...........................................21
+ 2.17. WLAN-Group-Mgmt-Cipher ...................................22
+ 2.18. WLAN-RF-Band .............................................23
+ 3. Table of Attributes ............................................24
+ 4. IANA Considerations ............................................25
+ 5. Security Considerations ........................................25
+ 6. References .....................................................26
+ 6.1. Normative References ......................................26
+ 6.2. Informative References ....................................27
+ 7. Acknowledgments ................................................28
+
+1. Introduction
+
+ In situations where it is desirable to centrally manage
+ authentication, authorization, and accounting (AAA) for IEEE 802
+ [IEEE-802] networks, deployment of a backend authentication and
+ accounting server is desirable. In such situations, it is expected
+ that IEEE 802 authenticators will function as AAA clients.
+
+ "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS)
+ Usage Guidelines" [RFC3580] provides guidelines for the use of the
+ Remote Authentication Dial-In User Service (RADIUS) within networks
+ utilizing IEEE 802 local area networks. This document defines
+ additional attributes suitable for usage by IEEE 802 authenticators
+ acting as AAA clients.
+
+
+
+
+
+Aboba, et al. Standards Track [Page 3]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+1.1. Terminology
+
+ This document uses the following terms:
+
+ Access Point (AP)
+ A Station that provides access to the distribution services via
+ the wireless medium for associated Stations.
+
+ Association
+ The service used to establish Access Point/Station mapping and
+ enable Station invocation of the distribution system services.
+
+ Authenticator
+ An entity that requires authentication from the Supplicant. The
+ authenticator may be connected to the Supplicant at the other end
+ of a point-to-point LAN segment or wireless link.
+
+ Authentication Server
+ An entity that provides an authentication service to an
+ authenticator. This service verifies the claim of identity made
+ by the Supplicant using the credentials provided by the Supplicant
+
+ Station (STA)
+ Any device that contains an IEEE 802.11 conformant Medium Access
+ Control (MAC) and Physical Layer (PHY) interface to the wireless
+ medium (WM).
+
+ Supplicant
+ An entity that is being authenticated by an authenticator. The
+ Supplicant may be connected to the authenticator at one end of a
+ point-to-point LAN segment or 802.11 wireless link.
+
+1.2. Requirements Language
+
+ In this document, several words are used to signify the requirements
+ of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 4]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+2. RADIUS Attributes
+
+2.1. Allowed-Called-Station-Id
+
+ Description
+
+ The Allowed-Called-Station-Id Attribute allows the RADIUS server
+ to specify the authenticator MAC addresses and/or networks to
+ which the user is allowed to connect. One or more Allowed-Called-
+ Station-Id Attributes MAY be included in an Access-Accept, CoA-
+ Request, or Accounting-Request packet.
+
+ The Allowed-Called-Station-Id Attribute can be useful in
+ situations where pre-authentication is supported (e.g., IEEE
+ 802.11 pre-authentication). In these scenarios, a Called-Station-
+ Id Attribute typically will not be included within the Access-
+ Request so that the RADIUS server will not know the network that
+ the user is attempting to access. The Allowed-Called-Station-Id
+ enables the RADIUS server to restrict the networks and attachment
+ points to which the user can subsequently connect.
+
+ A summary of the Allowed-Called-Station-Id Attribute format is
+ shown below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 174
+
+ Length
+
+ >=3
+
+ String
+
+ The String field is one or more octets, specifying a Called-
+ Station-Id that the user MAY connect to; if the Called-Station-Id
+ that the user connects to does not match one of the Allowed-
+ Called-Station-Id Attributes, the Network Access Server (NAS) MUST
+ NOT permit the user to access the network.
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 5]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ In the case of IEEE 802, the Allowed-Called-Station-Id Attribute
+ is used to store the Medium Access Control (MAC) address,
+ represented as an uppercase ASCII character string in Canonical
+ format and with octet values separated by a "-", for example,
+ "00-10-A4-23-19-C0". Where restrictions on both the network and
+ authenticator MAC address usage are intended, the network name
+ MUST be appended to the authenticator MAC address, separated from
+ the MAC address with a ":", for example, "00-10-A4-23-19-C0:AP1".
+ Where no MAC address restriction is intended, the MAC address
+ field MUST be omitted, but ":" and the network name field MUST be
+ included, for example, ":AP1".
+
+ Within IEEE 802.11 [IEEE-802.11], the Service Set Identifier
+ (SSID) constitutes the network name; within IEEE 802.1X
+ [IEEE-802.1X] wired networks, the Network-Id Name (NID-Name)
+ constitutes the network name. Since a NID-Name can be up to 253
+ octets in length, when used with [IEEE-802.1X] wired networks,
+ there may not be sufficient room within the Allowed-Called-
+ Station-Id Attribute to include both a MAC address and a network
+ name. However, as the Allowed-Called-Station-Id Attribute is
+ expected to be used largely in wireless access scenarios, this
+ restriction is not considered serious.
+
+2.2. EAP-Key-Name
+
+ Description
+
+ The EAP-Key-Name Attribute, defined in "Diameter Extensible
+ Authentication Protocol (EAP) Application" [RFC4072], contains the
+ EAP Session-Id, as described in "Extensible Authentication
+ Protocol (EAP) Key Management Framework" [RFC5247]. Exactly how
+ this attribute is used depends on the link layer in question.
+
+ It should be noted that not all link layers use this name. An
+ EAP-Key-Name Attribute MAY be included within Access-Request,
+ Access-Accept, and CoA-Request packets. A summary of the EAP-Key-
+ Name Attribute format is shown below. The fields are transmitted
+ from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 102 [RFC4072]
+
+
+
+Aboba, et al. Standards Track [Page 6]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ Length
+
+ >=3
+
+ String
+
+ The String field is one or more octets, containing the EAP
+ Session-Id, as defined in "Extensible Authentication Protocol
+ (EAP) Key Management Framework" [RFC5247]. Since the NAS operates
+ as a pass-through in EAP, it cannot know the EAP Session-Id before
+ receiving it from the RADIUS server. As a result, an EAP-Key-Name
+ Attribute sent in an Access-Request MUST only contain a single NUL
+ character. A RADIUS server receiving an Access-Request with an
+ EAP-Key-Name Attribute containing anything other than a single NUL
+ character MUST silently discard the attribute. In addition, the
+ RADIUS server SHOULD include this attribute in an Access-Accept or
+ CoA-Request only if an EAP-Key-Name Attribute was present in the
+ Access-Request. Since a NAS will typically only include an EAP-
+ Key-Name Attribute in an Access-Request in situations where the
+ attribute is required to provision service, if an EAP-Key-Name
+ Attribute is included in an Access-Request but is not present in
+ the Access-Accept, the NAS SHOULD treat the Access-Accept as
+ though it were an Access-Reject. If an EAP-Key-Name Attribute was
+ not present in the Access-Request but is included in the Access-
+ Accept, then the NAS SHOULD silently discard the EAP-Key-Name
+ Attribute. As noted in Section 6.2.2 of [IEEE-802.1X], the
+ Connectivity Association Key Name (CKN) is derived from the EAP
+ Session-Id, and, as described in Section 9.3.3 of [IEEE-802.1X],
+ the CKN is subsequently used in the derivation of the Key
+ Encrypting Key (KEK) and the Integrity Check Value Key (ICK),
+ which protect the Secure Association Keys (SAKs) utilized by Media
+ Access Control Security (MACsec). As a result, for the NAS to
+ acquire information needed in the MACsec Key Agreement (MKA)
+ exchange, it needs to include the EAP-Key-Name Attribute in the
+ Access-Request and receive it from the RADIUS server in the
+ Access-Accept.
+
+2.3. EAP-Peer-Id
+
+ Description
+
+ The EAP-Peer-Id Attribute contains a Peer-Id generated by the EAP
+ method. Exactly how this name is used depends on the link layer
+ in question. See [RFC5247] for more discussion. The EAP-Peer-Id
+ Attribute MAY be included in Access-Request, Access-Accept, and
+ Accounting-Request packets. More than one EAP-Peer-Id Attribute
+ MUST NOT be included in an Access-Request; one or more EAP-Peer-Id
+ Attributes MAY be included in an Access-Accept.
+
+
+
+Aboba, et al. Standards Track [Page 7]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ It should be noted that not all link layers use this name, and
+ existing EAP method implementations do not generate it. Since the
+ NAS operates as a pass-through in EAP [RFC3748], it cannot know
+ the EAP-Peer-Id before receiving it from the RADIUS server. As a
+ result, an EAP-Peer-Id Attribute sent in an Access-Request MUST
+ only contain a single NUL character. A home RADIUS server
+ receiving an Access-Request with an EAP-Peer-Id Attribute
+ containing anything other than a single NUL character MUST
+ silently discard the attribute. In addition, the home RADIUS
+ server SHOULD include one or more EAP-Peer-Id Attributes in an
+ Access-Accept only if an EAP-Peer-Id Attribute was present in the
+ Access-Request. If a NAS receives EAP-Peer-Id Attribute(s) in an
+ Access-Accept without having included one in an Access-Request,
+ the NAS SHOULD silently discard the attribute(s). A summary of
+ the EAP-Peer-Id Attribute format is shown below. The fields are
+ transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 175
+
+ Length
+
+ >=3
+
+ String
+
+ The String field is one or more octets, containing an EAP Peer-Id
+ exported by the EAP method. For details, see Appendix A of
+ [RFC5247]. A robust implementation SHOULD support the field as
+ undistinguished octets. Only a single EAP Peer-Id may be included
+ per attribute.
+
+2.4. EAP-Server-Id
+
+ Description
+
+ The EAP-Server-Id Attribute contains a Server-Id generated by the
+ EAP method. Exactly how this name is used depends on the link
+ layer in question. See [RFC5247] for more discussion. The EAP-
+ Server-Id Attribute is only allowed in Access-Request, Access-
+ Accept, and Accounting-Request packets. More than one EAP-Server-
+
+
+
+Aboba, et al. Standards Track [Page 8]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ Id Attribute MUST NOT be included in an Access-Request; one or
+ more EAP-Server-Id Attributes MAY be included in an Access-Accept.
+
+ It should be noted that not all link layers use this name, and
+ existing EAP method implementations do not generate it. Since the
+ NAS operates as a pass-through in EAP [RFC3748], it cannot know
+ the EAP-Server-Id before receiving it from the RADIUS server. As
+ a result, an EAP-Server-Id Attribute sent in an Access-Request
+ MUST contain only a single NUL character. A home RADIUS server
+ receiving an Access-Request with an EAP-Server-Id Attribute
+ containing anything other than a single NUL character MUST
+ silently discard the attribute. In addition, the home RADIUS
+ server SHOULD include this attribute in an Access-Accept only if
+ an EAP-Server-Id Attribute was present in the Access-Request. A
+ summary of the EAP-Server-Id Attribute format is shown below. The
+ fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 176
+
+ Length
+
+ >=3
+
+ String
+
+ The String field is one or more octets, containing an EAP Server-
+ Id exported by the EAP method. For details, see Appendix A of
+ [RFC5247]. A robust implementation SHOULD support the field as
+ undistinguished octets.
+
+2.5. Mobility-Domain-Id
+
+ Description
+
+ A single Mobility-Domain-Id Attribute MAY be included in an
+ Access-Request or Accounting-Request in order to enable the NAS to
+ provide the RADIUS server with the Mobility Domain Identifier
+ (MDID), defined in Section 8.4.2.49 of [IEEE-802.11]. A summary
+ of the Mobility-Domain-Id Attribute format is shown below. The
+ fields are transmitted from left to right.
+
+
+
+Aboba, et al. Standards Track [Page 9]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 177
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets, containing a 32-bit unsigned
+ integer. The two most significant octets MUST be set to zero by
+ the sender and are ignored by the receiver; the two least
+ significant octets contain the Mobility Domain Identifier (MDID)
+ defined in Section 8.4.2.49 of [IEEE-802.11].
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved | Mobility Domain Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.6. Preauth-Timeout
+
+ Description
+
+ This attribute sets the maximum number of seconds that pre-
+ authentication state is required to be kept by the NAS without
+ being utilized within a user session. For example, when
+ [IEEE-802.11] pre-authentication is used, if a user has not
+ attempted to utilize the Pairwise Master Key (PMK) derived as a
+ result of pre-authentication within the time specified by the
+ Preauth-Timeout Attribute, the PMK MAY be discarded by the Access
+ Point. However, once the session is underway, the Preauth-Timeout
+ Attribute has no bearing on the maximum session time for the user
+ or the maximum time during which key state may be kept prior to
+ re-authentication. This is determined by the Session-Timeout
+ Attribute, if present.
+
+
+
+
+
+Aboba, et al. Standards Track [Page 10]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ A single Preauth-Timeout Attribute MAY be included within an
+ Access-Accept or CoA-Request packet. A summary of the Preauth-
+ Timeout Attribute format is shown below. The fields are
+ transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 178
+
+ Length
+
+ 6
+
+ Value
+
+ The field is 4 octets, containing a 32-bit unsigned integer
+ encoding the maximum time in seconds that pre-authentication state
+ should be retained by the NAS.
+
+2.7. Network-Id-Name
+
+ Description
+
+ The Network-Id-Name Attribute is utilized by implementations of
+ IEEE-802.1X [IEEE-802.1X] to specify the name of a Network-Id
+ (NID-Name).
+
+ Unlike the IEEE 802.11 SSID (which is a maximum of 32 octets in
+ length), the NID-Name may be up to 253 octets in length.
+ Consequently, if the MAC address is included within the Called-
+ Station-Id Attribute, it is possible that there will not be enough
+ remaining space to encode the NID-Name as well. Therefore, when
+ used with IEEE 802.1X [IEEE-802.1X], the Called-Station-Id
+ Attribute SHOULD contain only the MAC address, with the Network-
+ Id-Name Attribute used to transmit the NID-Name. The Network-Id-
+ Name Attribute MUST NOT be used to encode the IEEE 802.11 SSID; as
+ noted in [RFC3580], the Called-Station-Id Attribute is used for
+ this purpose.
+
+
+
+
+
+Aboba, et al. Standards Track [Page 11]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ Zero or one Network-Id-Name Attribute is permitted within an
+ Access-Request, Access-Challenge, Access-Accept or Accounting-
+ Request packet. When included within an Access-Request packet,
+ the Network-Id-Name Attribute represents a hint of the NID-Name to
+ which the Supplicant should be granted access. When included
+ within an Access-Accept packet, the Network-Id-Name Attribute
+ represents the NID-Name to which the Supplicant is to be granted
+ access. When included within an Accounting-Request packet, the
+ Network-Id-Name Attribute represents the NID-Name to which the
+ Supplicant has been granted access.
+
+ A summary of the Network-Id-Name Attribute format is shown below.
+ The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 179
+
+ Length
+
+ >=3
+
+ String
+
+ The String field is one or more octets, containing a NID-Name.
+ For details, see [IEEE-802.1X]. A robust implementation SHOULD
+ support the field as undistinguished octets.
+
+2.8. EAPoL-Announcement
+
+ Description
+
+ The EAPoL-Announcement Attribute contains EAPoL-Announcement Type-
+ Length-Value (TLV) tuples defined within Table 11-8 of IEEE-802.1X
+ [IEEE-802.1X]. The acronym "EAPoL" stands for Extensible
+ Authentication Protocol over Local Area Network.
+
+ Zero or more EAPoL-Announcement Attributes are permitted within an
+ Access-Request, Access-Accept, Access-Challenge, Access-Reject,
+ Accounting-Request, CoA-Request, or Disconnect-Request packet.
+
+
+
+
+
+Aboba, et al. Standards Track [Page 12]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ When included within an Access-Request packet, EAPoL-Announcement
+ Attributes contain EAPoL-Announcement TLVs that the user sent in
+ an EAPoL-Announcement. When included within an Access-Accept,
+ Access-Challenge, Access-Reject, CoA-Request or Disconnect-Request
+ packet, EAPoL-Announcement Attributes contain EAPoL-Announcement
+ TLVs that the NAS is to send to the user in a unicast EAPoL-
+ Announcement. When sent within an Accounting-Request packet,
+ EAPoL-Announcement Attributes contain EAPoL-Announcement TLVs that
+ the NAS has most recently sent to the user in a unicast EAPoL-
+ Announcement.
+
+ A summary of the EAPoL-Announcement Attribute format is shown
+ below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 180
+
+ Length
+
+ >=3
+
+ String
+
+ The String field is one or more octets, containing EAPoL-
+ Announcement TLVs in the format defined in Figure 11-8 of Section
+ 11.12 of [IEEE-802.1X]. Any EAPoL-Announcement TLV Type MAY be
+ included within an EAPoL-Announcement Attribute, including
+ Organizationally Specific TLVs. If multiple EAPoL-Announcement
+ Attributes are present in a packet, their String fields MUST be
+ concatenated before being parsed for EAPoL-Announcement TLVs; this
+ allows EAPoL-Announcement TLVs longer than 253 octets to be
+ transported by RADIUS. Similarly, EAPoL-Announcement TLVs larger
+ than 253 octets MUST be fragmented between multiple EAPoL-
+ Announcement Attributes.
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 13]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+2.9. WLAN-HESSID
+
+ Description
+
+ The WLAN-HESSID Attribute contains a MAC address that identifies
+ the Homogenous Extended Service Set. The HESSID is a globally
+ unique identifier that, in conjunction with the SSID, encoded
+ within the Called-Station-Id Attribute as described in [RFC3580],
+ may be used to provide network identification for a subscription
+ service provider network (SSPN), as described in Section 8.4.2.94
+ of [IEEE-802.11]. Zero or one WLAN-HESSID Attribute is permitted
+ within an Access-Request or Accounting-Request packet.
+
+ A summary of the WLAN-HESSID Attribute format is shown below. The
+ fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 181
+
+ Length
+
+ 19
+
+ String
+
+ The String field is encoded in uppercase ASCII characters with the
+ octet values separated by dash characters, as described in RFC
+ 3580 [RFC3580], for example, "00-10-A4-23-19-C0".
+
+2.10. WLAN-Venue-Info
+
+ Description
+
+ The WLAN-Venue-Info Attribute identifies the category of venue
+ hosting the WLAN, as defined in Section 8.4.1.34 of [IEEE-802.11].
+ Zero or more WLAN-Venue-Info Attributes may be included in an
+ Access-Request or Accounting-Request.
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 14]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ A summary of the WLAN-Venue-Info Attribute format is shown below.
+ The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 182
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets, containing a 32-bit unsigned
+ integer. The two most significant octets MUST be set to zero by
+ the sender, and are ignored by the receiver; the two least
+ significant octets contain the Venue Group and Venue Type fields.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved | Venue Group | Venue Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Venue Group
+
+ The Venue Group field is a single octet and describes the broad
+ category of the venue, e.g., "Assembly". See Section 8.4.1.34
+ of [IEEE-802.11] for Venue Group codes and descriptions.
+
+ Venue Type
+
+ The Venue Type field is a single octet and describes the venue
+ in a finer granularity within the Venue Group, e.g., "Library".
+ See Section 8.4.1.34 of [IEEE-802.11] for Venue Type codes and
+ descriptions.
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 15]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+2.11. WLAN-Venue-Language
+
+ Description
+
+ The WLAN-Venue-Language Attribute is a string encoded by
+ ISO-14962-1997 [ISO-14962-1997] that defines the language used in
+ the WLAN-Venue-Name Attribute. Zero or more WLAN-Venue-Language
+ Attributes may be included in an Access-Request or Accounting-
+ Request, and each one indicates the language of the WLAN-Venue-
+ Name Attribute that follows it.
+
+ A summary of the WLAN-Venue-Language Attribute format is shown
+ below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ String (cont) |
+ +-+-+-+-+-+-+-+-+
+
+ Type
+
+ 183
+
+ Length
+
+ 4-5
+
+ String
+
+ The String field is a two- or three-character language code
+ selected from ISO-639 [ISO-639]. A two-character language code
+ has a zero ("null" in ISO-14962-1997) appended to make it 3 octets
+ in length.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 16]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+2.12. WLAN-Venue-Name
+
+ Description
+
+ The WLAN-Venue-Name Attribute provides additional metadata on the
+ Basic Service Set (BSS). For example, this information may be
+ used to assist a user in selecting the appropriate BSS with which
+ to associate. Zero or more WLAN-Venue-Name Attributes may be
+ included in an Access- Request or Accounting-Request in the same
+ or different languages.
+
+ A summary of the WLAN-Venue-Name Attribute format is shown below.
+ The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 184
+
+ Length
+
+ >=3
+
+ String
+
+ The String field is encoded in UTF-8 and contains the venue's
+ name. The maximum length of this field is 252 octets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 17]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+2.13. WLAN-Reason-Code
+
+ Description
+
+ The WLAN-Reason-Code Attribute contains information on the reason
+ why a Station has been refused network access and has been
+ disassociated or de-authenticated. This can occur due to policy
+ or for reasons related to the user's subscription.
+
+ A WLAN-Reason-Code Attribute MAY be included within an Access-
+ Reject or Disconnect-Request packet, as well as within an
+ Accounting-Request packet. Upon receipt of an Access-Reject or
+ Disconnect-Request packet containing a WLAN-Reason-Code Attribute,
+ the WLAN-Reason-Code value is copied by the Access Point into the
+ Reason Code field of a Disassociation or Deauthentication frame
+ (see Clauses 8.3.3.4 and 8.3.3.12, respectively, in
+ [IEEE-802.11]), which is subsequently transmitted to the Station.
+
+ A summary of the WLAN-Reason-Code Attribute format is shown below.
+ The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 185
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets, containing a 32-bit unsigned
+ integer. The two most significant octets MUST be set to zero by
+ the sender and are ignored by the receiver; the two least
+ significant octets contain the Reason Code values defined in Table
+ 8-36 of Section 8.4.1.7 of [IEEE-802.11].
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 18]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved | Reason Code |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.14. WLAN-Pairwise-Cipher
+
+ Description
+
+ The WLAN-Pairwise-Cipher Attribute contains information on the
+ pairwise ciphersuite used to establish the robust security network
+ association (RSNA) between the AP and mobile device. A WLAN-
+ Pairwise-Cipher Attribute MAY be included within Access-Request
+ and Accounting-Request packets.
+
+ A summary of the WLAN-Pairwise-Cipher Attribute format is shown
+ below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 186
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets, containing a 32-bit unsigned
+ integer, in Suite selector format as specified in Figure 8-187
+ within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and
+ Suite Type drawn from Table 8-99.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | OUI | Suite Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Aboba, et al. Standards Track [Page 19]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+2.15. WLAN-Group-Cipher
+
+ Description
+
+ The WLAN-Group-Cipher Attribute contains information on the group
+ ciphersuite used to establish the robust security network
+ association (RSNA) between the AP and mobile device. A WLAN-
+ Group-Cipher Attribute MAY be included within Access-Request and
+ Accounting-Request packets.
+
+ A summary of the WLAN-Group-Cipher Attribute format is shown
+ below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 187
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets, containing a 32-bit unsigned
+ integer, in Suite selector format as specified in Figure 8-187
+ within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and
+ Suite Type drawn from Table 8-99.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | OUI | Suite Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 20]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+2.16. WLAN-AKM-Suite
+
+ Description
+
+ The WLAN-AKM-Suite Attribute contains information on the
+ authentication and key management suite used to establish the
+ robust security network association (RSNA) between the AP and
+ mobile device. A WLAN-AKM-Suite Attribute MAY be included within
+ Access-Request and Accounting-Request packets.
+
+ A summary of the WLAN-AKM-Suite Attribute format is shown below.
+ The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 188
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets, containing a 32-bit unsigned
+ integer, in Suite selector format as specified in Figure 8-187
+ within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and
+ Suite Type drawn from Table 8-101:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | OUI | Suite Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 21]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+2.17. WLAN-Group-Mgmt-Cipher
+
+ Description
+
+ The WLAN-Group-Mgmt-Cipher Attribute contains information on the
+ group management cipher used to establish the robust security
+ network association (RSNA) between the AP and mobile device.
+
+ Zero or one WLAN-Group-Mgmt-Cipher Attribute MAY be included
+ within Access-Request and Accounting-Request packets. The
+ presence of the Attribute indicates that the Station negotiated to
+ use management frame protection during association.
+
+ A summary of the WLAN-Group-Mgmt-Cipher Attribute format is shown
+ below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 189
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets, containing a 32-bit unsigned
+ integer, in Suite selector format as specified in Figure 8-187
+ within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and
+ Suite Type drawn from Table 8-99:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | OUI | Suite Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 22]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+2.18. WLAN-RF-Band
+
+ Description
+
+ The WLAN-RF-Band Attribute contains information on the radio
+ frequency (RF) band used by the Access Point for transmission and
+ reception of information to and from the mobile device. Zero or
+ one WLAN-RF-Band Attribute MAY be included within an Access-
+ Request or Accounting-Request packet.
+
+ A summary of the WLAN-RF-Band Attribute format is shown below.
+ The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 190
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets, containing a 32-bit unsigned
+ integer. The three most significant octets MUST be set to zero by
+ the sender and are ignored by the receiver; the least significant
+ octet contains the RF Band field, whose values are defined by the
+ IEEE 802.11 Band ID field (Table 8-53a of [IEEE-802.11ad])
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved | RF Band |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 23]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+3. Table of Attributes
+
+ The following table provides a guide to which attributes may be found
+ in which kinds of packets and in what quantity.
+
+ Access- Access- Access- Access-
+ Request Accept Reject Challenge # Attribute
+ 0 0+ 0 0 174 Allowed-Called-Station-Id
+ 0-1 0-1 0 0 102 EAP-Key-Name
+ 0-1 0+ 0 0 175 EAP-Peer-Id
+ 0-1 0+ 0 0 176 EAP-Server-Id
+ 0-1 0 0 0 177 Mobility-Domain-Id
+ 0-1 0-1 0 0 178 Preauth-Timeout
+ 0-1 0 0 0 179 Network-Id-Name
+ 0+ 0+ 0+ 0+ 180 EAPoL-Announcement
+ 0-1 0 0 0 181 WLAN-HESSID
+ 0-1 0 0 0 182 WLAN-Venue-Info
+ 0+ 0 0 0 183 WLAN-Venue-Language
+ 0+ 0 0 0 184 WLAN-Venue-Name
+ 0 0 0-1 0 185 WLAN-Reason-Code
+ 0-1 0 0 0 186 WLAN-Pairwise-Cipher
+ 0-1 0 0 0 187 WLAN-Group-Cipher
+ 0-1 0 0 0 188 WLAN-AKM-Suite
+ 0-1 0 0 0 189 WLAN-Group-Mgmt-Cipher
+ 0-1 0 0 0 190 WLAN-RF-Band
+
+ CoA- Dis- Acct-
+ Req Req Req # Attribute
+ 0+ 0 0+ 174 Allowed-Called-Station-Id
+ 0-1 0 0 102 EAP-Key-Name
+ 0 0 0+ 175 EAP-Peer-Id
+ 0 0 0+ 176 EAP-Server-Id
+ 0 0 0-1 177 Mobility-Domain-Id
+ 0-1 0 0 178 Preauth-Timeout
+ 0 0 0-1 179 Network-Id-Name
+ 0+ 0+ 0+ 180 EAPoL-Announcement
+ 0 0 0-1 181 WLAN-HESSID
+ 0 0 0-1 182 WLAN-Venue-Info
+ 0 0 0+ 183 WLAN-Venue-Language
+ 0 0 0+ 184 WLAN-Venue-Name
+ 0 0-1 0-1 185 WLAN-Reason-Code
+ 0 0 0-1 186 WLAN-Pairwise-Cipher
+ 0 0 0-1 187 WLAN-Group-Cipher
+ 0 0 0-1 188 WLAN-AKM-Suite
+ 0 0 0-1 189 WLAN-Group-Mgmt-Cipher
+ 0 0 0-1 190 WLAN-RF-Band
+
+
+
+
+
+Aboba, et al. Standards Track [Page 24]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ The following table defines the above table entries.
+
+ 0 This attribute MUST NOT be present in packet.
+ 0+ Zero or more instances of this attribute MAY be present in the
+ packet.
+ 0-1 Zero or one instance of this attribute MAY be present in the
+ packet.
+
+4. IANA Considerations
+
+ This document uses the RADIUS [RFC2865] namespace; see
+ <http://www.iana.org/assignments/radius-types>. Per this
+ specification, RADIUS attribute types have been assigned for the
+ following attributes:
+
+ Attribute Type
+ ========= ====
+ Allowed-Called-Station-Id 174
+ EAP-Peer-Id 175
+ EAP-Server-Id 176
+ Mobility-Domain-Id 177
+ Preauth-Timeout 178
+ Network-Id-Name 179
+ EAPoL-Announcement 180
+ WLAN-HESSID 181
+ WLAN-Venue-Info 182
+ WLAN-Venue-Language 183
+ WLAN-Venue-Name 184
+ WLAN-Reason-Code 185
+ WLAN-Pairwise-Cipher 186
+ WLAN-Group-Cipher 187
+ WLAN-AKM-Suite 188
+ WLAN-Group-Mgmt-Cipher 189
+ WLAN-RF-Band 190
+
+ Since this specification relies entirely on values assigned by IEEE
+ 802, no registries are established for maintenance by the IANA.
+
+5. Security Considerations
+
+ Since this document describes the use of RADIUS for purposes of
+ authentication, authorization, and accounting in IEEE 802 networks,
+ it is vulnerable to all of the threats that are present in other
+ RADIUS applications. For a discussion of these threats, see
+ [RFC2607], [RFC2865], [RFC3162], [RFC3579], [RFC3580], and [RFC5176].
+ In particular, when RADIUS traffic is sent in the clear, the
+ attributes defined in this document can be obtained by an attacker
+
+
+
+
+Aboba, et al. Standards Track [Page 25]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ snooping the exchange between the RADIUS client and server. As a
+ result, RADIUS confidentiality is desirable; for a review of RADIUS
+ security and crypto-agility requirements, see [RFC6421].
+
+ While it is possible for a RADIUS server to make decisions on whether
+ to accept or reject an Access-Request based on the values of the
+ WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, WLAN-Group-
+ Mgmt-Cipher, and WLAN-RF-Band Attributes, the value of doing this is
+ limited. In general, an Access-Reject should not be necessary,
+ except where Access Points and Stations are misconfigured so as to
+ enable connections to be made with unacceptable values. Rather than
+ rejecting access on an ongoing basis, users would be better served by
+ fixing the misconfiguration.
+
+ Where access does need to be rejected, the user should be provided
+ with an indication of why the problem has occurred, or else they are
+ likely to become frustrated. For example, if the values of the WLAN-
+ Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, or WLAN-Group-
+ Mgmt-Cipher Attributes included in the Access-Request are not
+ acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute
+ with a value of 29 (Requested service rejected because of service
+ provider ciphersuite or AKM requirement) SHOULD be returned in the
+ Access-Reject. Similarly, if the value of the WLAN-RF-Band Attribute
+ included in the Access-Request is not acceptable to the RADIUS
+ server, then a WLAN-Reason-Code Attribute with a value of 11
+ (Disassociated because the information in the Supported Channels
+ element is unacceptable) SHOULD be returned in the Access-Reject.
+
+6. References
+
+6.1. Normative References
+
+ [IEEE-802] IEEE, "IEEE Standard for Local and Metropolitan Area
+ Networks: Overview and Architecture. Amendment 2:
+ Registration of Object Identifiers", ANSI/IEEE Std 802,
+ 2001.
+
+ [IEEE-802.11]
+ IEEE, "IEEE Standard for Information technology -
+ Telecommunications and information exchange between
+ systems - Local and metropolitan area networks - Specific
+ requirements Part 11: Wireless LAN Medium Access Control
+ (MAC) and Physical Layer (PHY) Specifications", IEEE Std
+ 802.11-2012, 2012.
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 26]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ [IEEE-802.11ad]
+ IEEE, "IEEE Standard for Information technology -
+ Telecommunications and information exchange between
+ systems - Local and metropolitan area networks - Specific
+ requirements Part 11: Wireless LAN Medium Access Control
+ (MAC) and Physical Layer (PHY) Specifications, Amendment
+ 3: Enhancements for Very High Throughput in the 60 GHz
+ Band", IEEE Std 802.11ad-2012, 2012.
+
+ [IEEE-802.1X]
+ IEEE, "IEEE Standard for Local and metropolitan area
+ networks - Port-Based Network Access Control", IEEE Std
+ 802.1X-2010, February 2010.
+
+ [ISO-639] ISO, "Codes for the Representation of Names of Languages",
+ ISO 639.
+
+ [ISO-14962-1997]
+ ISO, "Space data and information transfer systems - ASCII
+ encoded English", 1997.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+ "Remote Authentication Dial In User Service (RADIUS)", RFC
+ 2865, June 2000.
+
+ [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
+ Extensible Authentication Protocol (EAP) Application", RFC
+ 4072, August 2005.
+
+ [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
+ Authentication Protocol (EAP) Key Management Framework",
+ RFC 5247, August 2008.
+
+6.2. Informative References
+
+ [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
+ Implementation in Roaming", RFC 2607, June 1999.
+
+ [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC
+ 3162, August 2001.
+
+ [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
+ Dial In User Service) Support For Extensible
+ Authentication Protocol (EAP)", RFC 3579, September 2003.
+
+
+
+
+Aboba, et al. Standards Track [Page 27]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+ [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
+ "IEEE 802.1X Remote Authentication Dial In User Service
+ (RADIUS) Usage Guidelines", RFC 3580, September 2003.
+
+ [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+ Levkowetz, Ed., "Extensible Authentication Protocol
+ (EAP)", RFC 3748, June 2004.
+
+ [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
+ Aboba, "Dynamic Authorization Extensions to Remote
+ Authentication Dial In User Service (RADIUS)", RFC 5176,
+ January 2008.
+
+ [RFC6421] Nelson, D., Ed., "Crypto-Agility Requirements for Remote
+ Authentication Dial-In User Service (RADIUS)", RFC 6421,
+ November 2011.
+
+7. Acknowledgments
+
+ The authors would like to acknowledge Maximilian Riegel, Dorothy
+ Stanley, Yoshihiro Ohba, and the contributors to the IEEE 802.1 and
+ IEEE 802.11 reviews of this document, for useful discussions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 28]
+\f
+RFC 7268 RADIUS Attributes for IEEE 802 July 2014
+
+
+Authors' Addresses
+
+ Bernard Aboba
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+ US
+
+ EMail: bernard_aboba@hotmail.com
+
+
+ Jouni Malinen
+
+ EMail: j@w1.fi
+
+
+ Paul Congdon
+ Tallac Networks
+ 6528 Lonetree Blvd.
+ Rocklin, CA 95765
+ US
+
+ Phone: +19167576350
+ EMail: paul.congdon@tallac.com
+
+
+ Joseph Salowey
+ Cisco Systems
+
+ EMail: jsalowey@cisco.com
+
+
+ Mark Jones
+ Azuca Systems
+
+ EMail: mark@azu.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Standards Track [Page 29]
+\f
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. DeKok
+Request for Comments: 7542 FreeRADIUS
+Obsoletes: 4282 May 2015
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ The Network Access Identifier
+
+Abstract
+
+ In order to provide inter-domain authentication services, it is
+ necessary to have a standardized method that domains can use to
+ identify each other's users. This document defines the syntax for
+ the Network Access Identifier (NAI), the user identifier submitted by
+ the client prior to accessing resources. This document is a revised
+ version of RFC 4282. It addresses issues with international
+ character sets and makes a number of other corrections to RFC 4282.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7542.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 1]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 2]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Terminology ................................................6
+ 1.2. Requirements Language ......................................7
+ 1.3. Purpose ....................................................7
+ 1.4. Motivation .................................................9
+ 2. NAI Definition .................................................10
+ 2.1. UTF-8 Syntax and Normalization ............................10
+ 2.2. Formal Syntax .............................................11
+ 2.3. NAI Length Considerations .................................11
+ 2.4. Support for Username Privacy ..............................12
+ 2.5. International Character Sets ..............................13
+ 2.6. The Normalization Process .................................14
+ 2.6.1. Issues with the Normalization Process ..............15
+ 2.7. Use in Other Protocols ....................................16
+ 2.8. Using the NAI Format for Other Identifiers ................17
+ 3. Routing inside of AAA Systems ..................................18
+ 3.1. Compatibility with Email Usernames ........................19
+ 3.2. Compatibility with DNS ....................................20
+ 3.3. Realm Construction ........................................20
+ 3.3.1. Historical Practices ...............................21
+ 3.4. Examples ..................................................22
+ 4. Security Considerations ........................................23
+ 4.1. Correlation of Identities over Time and Protocols .........23
+ 4.2. Multiple Identifiers ......................................24
+ 5. Administration of Names ........................................25
+ 6. References .....................................................26
+ 6.1. Normative References ......................................26
+ 6.2. Informative References ....................................26
+ Appendix A. Changes from RFC 4282 .................................29
+ Acknowledgments ...................................................30
+ Author's Address ..................................................30
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 3]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+1. Introduction
+
+ Considerable interest exists for a set of features that fit within
+ the general category of inter-domain authentication, or "roaming
+ capability" for network access, including dialup Internet users,
+ Virtual Private Network (VPN) usage, wireless LAN authentication, and
+ other applications.
+
+ By "inter-domain authentication", this document refers to situations
+ where a user has authentication credentials at one "home" domain but
+ is able to present them at a second "visited" domain to access
+ certain services at the visited domain. The two domains generally
+ have a pre-existing relationship, so that the credentials can be
+ passed from the visited domain to the home domain for verification.
+ The home domain typically responds with a permit/deny response, which
+ may also include authorization parameters that the visited domain is
+ expected to enforce on the user.
+
+ That is, the "roaming" scenario involves a user visiting, or
+ "roaming" to, a non-home domain and requesting the use of services at
+ that visited domain.
+
+ Interested parties have included the following:
+
+ * Regional Internet Service Providers (ISPs) operating within a
+ particular state or province, looking to combine their efforts
+ with those of other regional providers to offer dialup service
+ over a wider area.
+
+ * Telecommunications companies who wish to combine their operations
+ with those of one or more companies in other areas or nations, in
+ order to offer more comprehensive network access service in areas
+ where there is no native service (e.g., in another country).
+
+ * Wireless LAN hotspots providing service to one or more ISPs.
+
+ * Businesses desiring to offer their employees a comprehensive
+ package of dialup services on a global basis. Those services may
+ include Internet access as well as secure access to corporate
+ intranets via a VPN, enabled by tunneling protocols such as the
+ Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2
+ Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling
+ Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC4301].
+
+ * Other protocols that are interested in leveraging the users'
+ credentials in order to take advantage of an existing
+ authentication framework.
+
+
+
+
+DeKok Standards Track [Page 4]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ In order to enhance the interoperability of these services, it is
+ necessary to have a standardized method for identifying users. This
+ document defines syntax for the Network Access Identifier (NAI).
+ Examples of implementations that use the NAI, and descriptions of its
+ semantics, can be found in [RFC2194].
+
+ When the NAI was defined for network access, it had the side effect
+ of defining an identifier that could be used in non-AAA systems.
+ Some non-AAA systems defined identifiers that were compatible with
+ the NAI, and deployments used the NAI. This process simplified the
+ management of credentials, by reusing the same credential in multiple
+ situations. Protocols that reuse the same credential or the same
+ identifier format can benefit from this simplified management. The
+ alternative is to have protocol-specific credentials or identifier
+ formats, which increases cost to both the user and the administrator.
+
+ There are privacy implications to using one identifier across
+ multiple protocols. See Sections 2.7 and 4 for further discussion of
+ this topic.
+
+ The goal of this document is to define the format of an identifier
+ that can be used in many protocols. A protocol may transport an
+ encoded version of the NAI (e.g., '.' as %2E). However, the
+ definition of the NAI is protocol independent. The goal of this
+ document is to encourage the widespread adoption of the NAI format.
+ This adoption will decrease the work required to leverage
+ identification and authentication in other protocols. It will also
+ decrease the complexity of non-AAA systems for end users and
+ administrators.
+
+ This document only suggests that the NAI format be used; it does not
+ require such use. Many protocols already define their own identifier
+ formats. Some of these are incompatible with the NAI, while others
+ allow the NAI in addition to non-NAI identifiers. The definition of
+ the NAI in this document has no requirements on protocol
+ specifications, implementations, or deployments.
+
+ However, this document suggests that using one standard identifier
+ format is preferable to using multiple incompatible identifier
+ formats. Where identifiers need to be used in new protocols and/or
+ specifications, it is RECOMMENDED that the format of the NAI be used.
+ That is, the interpretation of the identifier is context specific,
+ while the format of the identifier remains the same. These issues
+ are discussed in more detail in Section 2.8, below.
+
+
+
+
+
+
+
+DeKok Standards Track [Page 5]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ The recommendation for a standard identifier format is not a
+ recommendation that each user have one universal identifier. In
+ contrast, this document allows for the use of multiple identifiers
+ and recommends the use of anonymous identifiers where those
+ identifiers are publicly visible.
+
+ This document is a revised version of [RFC4282], which originally
+ defined internationalized NAIs. Differences and enhancements
+ compared to that document are listed in Appendix A.
+
+1.1. Terminology
+
+ This document frequently uses the following terms:
+
+ "Local" or "Localized" Text
+
+ "Local" or "localized" text is text that is in either non-UTF-8 or
+ non-normalized form. The character set, encoding, and locale are
+ (in general) unknown to Authentication, Authorization, and
+ Accounting (AAA) network protocols. The client that "knows" the
+ locale may have a different concept of this text than other AAA
+ entities, which do not know the same locale.
+
+ Network Access Identifier
+
+ The Network Access Identifier (NAI) is a common format for user
+ identifiers submitted by a client during authentication. The
+ purpose of the NAI is to allow a user to be associated with an
+ account name, as well as to assist in the routing of the
+ authentication request across multiple domains. Please note that
+ the NAI may not necessarily be the same as the user's email
+ address or the user identifier submitted in an application-layer
+ authentication.
+
+ Network Access Server
+
+ The Network Access Server (NAS) is the device that clients connect
+ to in order to get access to the network. In PPTP terminology,
+ this is referred to as the PPTP Access Concentrator (PAC), and in
+ L2TP terminology, it is referred to as the L2TP Access
+ Concentrator (LAC). In IEEE 802.11, it is referred to as an
+ Access Point.
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 6]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ Roaming Capability
+
+ Roaming capability can be loosely defined as the ability to use
+ any one of multiple Internet Service Providers (ISPs), while
+ maintaining a formal customer-vendor relationship with only one.
+ Examples of cases where roaming capability might be required
+ include ISP "confederations" and ISP-provided corporate network
+ access support.
+
+ Normalization or Canonicalization
+
+ These terms are defined in Section 4 of [RFC6365]; those
+ definitions are incorporated here by reference.
+
+ Locale
+
+ This term is defined in [RFC6365], Section 8; that definition is
+ incorporated here by reference.
+
+ Tunneling Service
+
+ A tunneling service is any network service enabled by tunneling
+ protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One
+ example of a tunneling service is secure access to corporate
+ intranets via a Virtual Private Network (VPN).
+
+1.2. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+1.3. Purpose
+
+ As described in [RFC2194], there are a number of providers offering
+ network access services, and essentially all Internet Service
+ Providers are involved in roaming consortia.
+
+ In order to be able to offer roaming capability, one of the
+ requirements is to be able to identify the user's home authentication
+ server. For use in roaming, this function is accomplished via the
+ Network Access Identifier (NAI) submitted by the user to the NAS in
+ the initial network authentication. It is also expected that NASes
+ will use the NAI as part of the process of opening a new tunnel, in
+ order to determine the tunnel endpoint.
+
+
+
+
+
+DeKok Standards Track [Page 7]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ This document suggests that other protocols can take advantage of the
+ NAI format. Many protocols include authentication capabilities,
+ including defining their own identifier formats. These identifiers
+ can then end up being transported in AAA protocols, so that the
+ originating protocols can leverage AAA for user authentication.
+ There is therefore a need for a definition of a user identifier that
+ can be used in multiple protocols.
+
+ While the NAI is defined herein, it should be noted that existing
+ protocols and deployments do not always use it. AAA systems MUST
+ therefore be able to handle user identifiers that are not in the NAI
+ format. The process by which that is done is outside of the scope of
+ this document.
+
+ Non-AAA systems can accept user identifiers in forms other than the
+ NAI. This specification does not forbid that practice. It only
+ codifies the format and interpretation of the NAI. This document
+ cannot change existing protocols or practices. It can, however,
+ suggest that using a consistent form for a user identifier is of
+ benefit to the community.
+
+ This document does not make any protocol-specific definitions for an
+ identifier format, and it does not make changes to any existing
+ protocol. Instead, it defines a protocol-independent form for the
+ NAI. It is hoped that the NAI is a user identifier that can be used
+ in multiple protocols.
+
+ Using a common identifier format simplifies protocols requiring
+ authentication, as they no longer need to specify a protocol-specific
+ format for user identifiers. It increases security, as multiple
+ identifier formats allow attackers to make contradictory claims
+ without being detected (see Section 4.2 for further discussion of
+ this topic). It simplifies deployments, as a user can have one
+ identifier in multiple contexts, which allows them to be uniquely
+ identified, so long as that identifier is itself protected against
+ unauthorized access.
+
+ In short, having a standard is better than having no standard at all.
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 8]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+1.4. Motivation
+
+ The changes from [RFC4282] are listed in detail in Appendix A.
+ However, some additional discussion is appropriate to motivate those
+ changes.
+
+ The motivation to revise [RFC4282] began with internationalization
+ concerns raised in the context of [EDUROAM]. Section 2.1 of
+ [RFC4282] defines ABNF for realms and limits the realm grammar to
+ English letters, digits, and the hyphen "-" character. The intent
+ appears to have been to encode, compare, and transport realms with
+ the Punycode [RFC3492] encoding form as described in [RFC5891].
+ There are a number of problems with this approach:
+
+ * The [RFC4282] ABNF is not aligned with internationalization
+ of DNS.
+
+ * The requirement in Section 2.1 of [RFC4282] that realms are ASCII
+ conflicts with the Extensible Authentication Protocol (EAP) as
+ defined in [RFC3748], and RADIUS, which are both 8-bit clean, and
+ which both recommend the use of UTF-8 for identifiers.
+
+ * Section 2.4 of [RFC4282] required mappings that are language
+ specific and that are nearly impossible for intermediate nodes to
+ perform correctly without information about that language.
+
+ * Section 2.4 of [RFC4282] requires normalization of usernames,
+ which may conflict with local system or administrative
+ requirements.
+
+ * The recommendations in Section 2.4 of [RFC4282] for treatment of
+ bidirectional characters have proven to be unworkable.
+
+ * The prohibition of the use of unassigned code points in
+ Section 2.4 of [RFC4282] effectively prohibits support for new
+ scripts.
+
+ * No Authentication, Authorization, and Accounting (AAA) client,
+ proxy, or server has implemented any of the requirements in
+ Section 2.4 of [RFC4282], among other sections.
+
+ With international roaming growing in popularity, it is important for
+ these issues to be corrected in order to provide robust and
+ interoperable network services.
+
+ Furthermore, this document was motivated by a desire to codify
+ existing practice related to the use of the NAI format and to
+ encourage widespread use of the format.
+
+
+
+DeKok Standards Track [Page 9]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+2. NAI Definition
+
+2.1. UTF-8 Syntax and Normalization
+
+ UTF-8 characters can be defined in terms of octets using the
+ following ABNF [RFC5234], taken from [RFC3629]:
+
+ UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4
+
+ UTF8-2 = %xC2-DF UTF8-tail
+
+ UTF8-3 = %xE0 %xA0-BF UTF8-tail /
+ %xE1-EC 2( UTF8-tail ) /
+ %xED %x80-9F UTF8-tail /
+ %xEE-EF 2( UTF8-tail )
+
+ UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) /
+ %xF1-F3 3( UTF8-tail ) /
+ %xF4 %x80-8F 2( UTF8-tail )
+
+ UTF8-tail = %x80-BF
+
+ These are normatively defined in [RFC3629] but are repeated in this
+ document for reasons of convenience.
+
+ See [RFC5198] and Section 2.6 of this specification for a discussion
+ of normalization. Strings that are not Normal Form Composed (NFC)
+ are not valid NAIs and SHOULD NOT be treated as such.
+ Implementations that expect to receive an NAI but that instead
+ receive non-normalized (but otherwise valid) UTF-8 strings instead
+ SHOULD attempt to create a local version of the NAI, which is
+ normalized from the input identifier. This local version can then be
+ used for local processing. This local version of the identifier MUST
+ NOT be used outside of the local context.
+
+ Where protocols carry identifiers that are expected to be transported
+ over a AAA protocol, it is RECOMMENDED that the identifiers be in NAI
+ format. Where the identifiers are not in the NAI format, it is up to
+ the AAA systems to discover this and to process them. This document
+ does not suggest how that is done. However, existing practice
+ indicates that it is possible.
+
+ As internationalized domain names become more widely used, existing
+ practices are likely to become inadequate. This document therefore
+ defines the NAI, which is a user identifier format that can correctly
+ deal with internationalized identifiers.
+
+
+
+
+
+DeKok Standards Track [Page 10]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+2.2. Formal Syntax
+
+ The grammar for the NAI is given below, described in Augmented
+ Backus-Naur Form (ABNF) as documented in [RFC5234].
+
+ nai = utf8-username
+ nai =/ "@" utf8-realm
+ nai =/ utf8-username "@" utf8-realm
+
+ utf8-username = dot-string
+
+ dot-string = string *("." string)
+ string = 1*utf8-atext
+
+ utf8-atext = ALPHA / DIGIT /
+ "!" / "#" /
+ "$" / "%" /
+ "&" / "'" /
+ "*" / "+" /
+ "-" / "/" /
+ "=" / "?" /
+ "^" / "_" /
+ "`" / "{" /
+ "|" / "}" /
+ "~" /
+ UTF8-xtra-char
+
+ utf8-realm = 1*( label "." ) label
+
+ label = utf8-rtext *(ldh-str)
+ ldh-str = *( utf8-rtext / "-" ) utf8-rtext
+ utf8-rtext = ALPHA / DIGIT / UTF8-xtra-char
+
+2.3. NAI Length Considerations
+
+ Devices handling NAIs MUST support an NAI length of at least
+ 72 octets. Devices SHOULD support an NAI length of 253 octets.
+ However, the following implementation issues should be considered:
+
+ * NAI octet length constraints may impose a more severe constraint
+ on the number of UTF-8 characters.
+
+ * NAIs are often transported in the User-Name attribute of the
+ Remote Authentication Dial-In User Service (RADIUS) protocol.
+ Unfortunately, [RFC2865], Section 5.1 states that "the ability to
+ handle at least 63 octets is recommended." As a result, it may
+ not be possible to transfer NAIs beyond 63 octets through all
+ devices. In addition, since only a single User-Name attribute may
+
+
+
+DeKok Standards Track [Page 11]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ be included in a RADIUS message and the maximum attribute length
+ is 253 octets, RADIUS is unable to support NAI lengths beyond
+ 253 octets.
+
+ * NAIs can also be transported in the User-Name attribute of
+ Diameter [RFC6733], which supports content lengths up to
+ 2^24 - 9 octets. As a result, NAIs processed only by Diameter
+ nodes can be very long. However, an NAI transported over Diameter
+ may eventually be translated to RADIUS, in which case the above
+ limitations will apply.
+
+ * NAIs may be transported in other protocols. Each protocol can
+ have its own limitations on maximum NAI length.
+
+ The above criteria should permit the widest use and widest possible
+ interoperability of the NAI.
+
+2.4. Support for Username Privacy
+
+ Interpretation of the username part of the NAI depends on the realm
+ in question. Therefore, the utf8-username portion SHOULD be treated
+ as opaque data when processed by nodes that are not a part of the
+ home domain for that realm.
+
+ That is, the only domain that is capable of interpreting the meaning
+ of the utf8-username portion of the NAI is the home domain. Any
+ third-party domains cannot form any conclusions about the
+ utf8-username and cannot decode it into subfields. For example, it
+ may be used as "firstname.lastname", or it may be entirely digits, or
+ it may be a random hex identifier. There is simply no way (and no
+ reason) for any other domain to interpret the utf8-username field as
+ having any meaning whatsoever.
+
+ In some situations, NAIs are used together with a separate
+ authentication method that can transfer the username part in a more
+ secure manner to increase privacy. In this case, NAIs MAY be
+ provided in an abbreviated form by omitting the username part.
+ Omitting the username part is RECOMMENDED over using a fixed username
+ part, such as "anonymous", since including a fixed username part is
+ ambiguous as to whether or not the NAI refers to a single user.
+ However, current practice is to use the username "anonymous" instead
+ of omitting the username part. This behavior is also permitted.
+
+ The most common use case of omitting or obfuscating the username part
+ is with TLS-based EAP methods such as Tunneled Transport Layer
+ Security (TTLS) [RFC5281]. Those methods allow for an "outer"
+ identifier, which is typically an anonymous "@realm". This outer
+ identifier allows the authentication request to be routed from a
+
+
+
+DeKok Standards Track [Page 12]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ visited domain to a home domain. At the same time, the username part
+ is kept confidential from the visited network. The protocol provides
+ for an "inner" authentication exchange, in which a full identifier is
+ used to authenticate a user.
+
+ That scenario offers the best of both worlds. An anonymous NAI can
+ be used to route authentication to the home domain, and the home
+ domain has sufficient information to identify and authenticate users.
+
+ However, some protocols do not support authentication methods that
+ allow for "inner" and "outer" exchanges. Those protocols are limited
+ to using an identifier that is publicly visible. It is therefore
+ RECOMMENDED that such protocols use ephemeral identifiers. We
+ recognize that this practice is not currently used and will likely be
+ difficult to implement.
+
+ Similar to the anonymous user, there may be situations where portions
+ of the realm are sensitive. For those situations, it is RECOMMENDED
+ that the sensitive portion of the realm also be omitted (e.g., to use
+ "@example.com" instead of "@sensitive.example.com", or
+ "anonymous@sensitive.example.com"). The home domain is authoritative
+ for users in all subdomains and can (if necessary) route the
+ authentication request to the appropriate subsystem within the home
+ domain.
+
+ For roaming purposes, it is typically necessary to locate the
+ appropriate backend authentication server for the given NAI before
+ the authentication conversation can proceed. As a result,
+ authentication routing is impossible unless the realm portion is
+ available and is in a well-known format.
+
+2.5. International Character Sets
+
+ This specification allows both international usernames and realms.
+ International usernames are based on the use of Unicode characters,
+ encoded as UTF-8. Internationalization of the username portion of
+ the NAI is based on the "Internationalized Email Headers" [RFC6532]
+ extensions to the "local-part" portion of email addresses [RFC5322].
+
+ In order to ensure a canonical representation, characters of the
+ realm portion in an NAI MUST match the ABNF in this specification as
+ well as the requirements specified in [RFC5891]. In practice, these
+ requirements consist of the following item:
+
+ * Realms MUST be of the form that can be registered as a Fully
+ Qualified Domain Name (FQDN) within the DNS.
+
+
+
+
+
+DeKok Standards Track [Page 13]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ This list is significantly shorter and simpler than the list in
+ Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended
+ on intermediate nodes performing canonicalizations based on
+ insufficient information, which meant that the form was not
+ canonical.
+
+ Specifying the realm requirement as above means that the requirements
+ depend on specifications that are referenced here, rather than copied
+ here. This allows the realm definition to be updated when the
+ referenced documents change, without requiring a revision of this
+ specification.
+
+ One caveat on the above recommendation is the issues noted in
+ [RFC6912]. That document notes that there are additional
+ restrictions around DNS registration that forbid some code points
+ from being valid in a DNS U-label. These restrictions cannot be
+ expressed algorithmically.
+
+ For this specification, that caveat means the following:
+ Realms not matching the above ABNF are not valid NAIs. However, some
+ realms that do match the ABNF are still invalid NAIs. That is,
+ matching the ABNF is a necessary, but not sufficient, requirement for
+ an NAI.
+
+ In general, the above requirement means following the requirements
+ specified in [RFC5891].
+
+2.6. The Normalization Process
+
+ Conversion to Unicode as well as normalization SHOULD be performed by
+ edge systems (e.g., laptops, desktops, smart phones, etc.) that take
+ "local" text as input. These edge systems are best suited to
+ determine the user's intent and can best convert from "local" text to
+ a normalized form.
+
+ Other AAA systems such as proxies do not have access to locale and
+ character set information that is available to edge systems.
+ Therefore, they may not always be able to convert local input to
+ Unicode.
+
+ That is, all processing of NAIs from "local" character sets and
+ locales to UTF-8 SHOULD be performed by edge systems, prior to the
+ NAIs entering the AAA system. Inside of a AAA system, NAIs are sent
+ over the wire in their canonical form, and this canonical form is
+ used for all NAI and/or realm comparisons.
+
+
+
+
+
+
+DeKok Standards Track [Page 14]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ Copying of localized text into fields that can subsequently be placed
+ into the RADIUS User-Name attribute is problematic. This practice
+ can result in a AAA proxy encountering non-UTF-8 characters within
+ what it expects to be an NAI. An example of this requirement is
+ Section 2.1 of [RFC3579], which states:
+
+ the NAS MUST copy the contents of the Type-Data field of the
+ EAP-Response/Identity received from the peer into the User-Name
+ attribute
+
+ As a result, AAA proxies expect the contents of the
+ EAP-Response/Identity sent by an EAP supplicant to consist of UTF-8
+ characters, not localized text. Using localized text in AAA username
+ or identity fields means that realm routing becomes difficult or
+ impossible.
+
+ In contrast to Section 2.4 of [RFC4282], AAA systems are now expected
+ to perform NAI comparisons, matching, and AAA routing based on the
+ NAI as it is received. This specification provides a canonical
+ representation, ensures that intermediate AAA systems such as proxies
+ are not required to perform translations, and can be expected to work
+ through AAA systems that are unaware of international character sets.
+
+ In an ideal world, the following requirements would be widely
+ implemented:
+
+ * Edge systems using "localized" text SHOULD normalize the NAI prior
+ to it being used as an identifier in an authentication protocol.
+
+ * AAA systems SHOULD NOT normalize the NAI, as they may not have
+ sufficient information to perform the normalization.
+
+ There are issues with this approach, however.
+
+2.6.1. Issues with the Normalization Process
+
+ The requirements in the preceding section are not implemented today.
+ For example, most EAP implementations use a user identifier that is
+ passed to them from some other local system. This identifier is
+ treated as an opaque blob and is placed as is into the EAP Identity
+ field. Any subsequent system that receives that identifier is
+ assumed to be able to understand and process it.
+
+ This opaque blob unfortunately can contain localized text, which
+ means that the AAA systems have to process that text.
+
+
+
+
+
+
+DeKok Standards Track [Page 15]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ These limitations have the following theoretical and practical
+ implications:
+
+ * Edge systems used today generally do not normalize the NAI.
+
+ * Therefore, AAA systems SHOULD attempt to normalize the NAI.
+
+ The suggestions above contradict the suggestions in the previous
+ section. This is the reality of imperfect protocols.
+
+ Where the user identifier can be normalized, or determined to be in
+ normal form, the normal form MUST be used as the NAI. In all other
+ circumstances, the user identifier MUST NOT be treated as an NAI.
+ That data is still, however, a user identifier. AAA systems MUST NOT
+ fail authentication simply because the user identifier is not an NAI.
+
+ That is, when the realm portion of the NAI is not recognized by a AAA
+ server, it SHOULD try to normalize the NAI into NFC form. That
+ normalized form can then be used to see if the realm matches a known
+ realm. If no match is found, the original form of the NAI SHOULD be
+ used in all subsequent processing.
+
+ The AAA server may also convert realms to Punycode and perform all
+ realm comparisons on the resulting Punycode strings. This conversion
+ follows the recommendations above but may have different operational
+ effects and failure modes.
+
+2.7. Use in Other Protocols
+
+ As noted earlier, the NAI format can be used in other, non-AAA
+ protocols. It is RECOMMENDED that the definition given here be used
+ unchanged. Using other definitions for user identifiers may hinder
+ interoperability, along with the user's ability to authenticate
+ successfully. It is RECOMMENDED that protocols requiring the use of
+ a user identifier use the NAI format.
+
+ This document cannot require other protocols to use the NAI format
+ for user identifiers. Their needs are unknown and, at this time,
+ unknowable. This document suggests that interoperability and
+ inter-domain authentication are useful and should be encouraged.
+
+ Where a protocol is 8-bit clean, it can likely transport the NAI as
+ is, without further modification.
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 16]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ Where a protocol is not 8-bit clean, it cannot transport the NAI as
+ is. Instead, this document presumes that a protocol-specific
+ transport layer takes care of encoding the NAI on input to the
+ protocol and decoding it when the NAI exits the protocol. The
+ encoded or escaped version of the NAI is not a valid NAI and MUST NOT
+ be presented to the AAA system.
+
+ For example, HTTP carries user identifiers but escapes the '.'
+ character as "%2E" (among others). When HTTP is used to transport
+ the NAI "fred@example.com", the data as transported will be in the
+ form "fred@example%2Ecom". That data exists only within HTTP and has
+ no relevance to any AAA system.
+
+ Any comparison, validation, or use of the NAI MUST be done on its
+ unescaped (i.e., utf8-clean) form.
+
+2.8. Using the NAI Format for Other Identifiers
+
+ As discussed in Section 1, above, it is RECOMMENDED that the NAI
+ format be used as the standard format for user identifiers. This
+ section discusses that use in more detail.
+
+ It is often useful to create new identifiers for use in specific
+ contexts. These identifiers may have a number of different
+ properties, most of which are unimportant to this document. The
+ goal of this document is to create identifiers that are to be in a
+ well-known format and that will have namespaces. The NAI format fits
+ these requirements.
+
+ One example of such use is the "private user identity", which is an
+ identifier defined by the 3rd Generation Partnership Project (3GPP).
+ That identifier is used to uniquely identify the user to the network.
+ The identifier is used for authorization, authentication, accounting,
+ administration, etc. The "private user identity" is globally unique
+ and is defined by the home network operator. The format of the
+ identifier is explicitly the NAI, as stated by Section 13.3 of
+ [3GPP]:
+
+ The private user identity shall take the form of an NAI, and shall
+ have the form username@realm as specified in clause 2.1 of IETF
+ RFC 4282
+
+ For 3GPP, the "username" portion is a unique identifier that is
+ derived from device-specific information. The "realm" portion is
+ composed of information about the home network, followed by the base
+ string "3gppnetwork.org" (e.g.,
+ 234150999999999@ims.mnc015.mcc234.3gppnetwork.org).
+
+
+
+
+DeKok Standards Track [Page 17]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ This format as defined by 3GPP ensures that the identifier is
+ globally unique, as it is based on the "3gppnetwork.org" domain. It
+ ensures that the "realm" portion is specific to a particular home
+ network (or organization), via the "ims.mnc015.mcc234" prefix to the
+ realm. Finally, it ensures that the "username" portion follows a
+ well-known format.
+
+ This document suggests that the NAI format be used for all new
+ specifications and/or protocols where a user identifier is required.
+ Where the username portions need to be created with subfields, a
+ well-known and documented method, as has been done with 3GPP, is
+ preferred to ad hoc methods.
+
+3. Routing inside of AAA Systems
+
+ Many AAA systems use the "utf8-realm" portion of the NAI to route
+ requests within a AAA proxy network. The semantics of this operation
+ involves a logical AAA routing table, where the "utf8-realm" portion
+ acts as a key, and the values stored in the table are one or more
+ "next hop" AAA servers.
+
+ Intermediate nodes MUST use the "utf8-realm" portion of the NAI
+ without modification to perform this lookup. As noted earlier,
+ intermediate nodes may not have access to the same locale information
+ as the system that injected the NAI into the AAA routing systems.
+ Therefore, almost all "case insensitive" comparisons can be wrong.
+ Where the "utf8-realm" is entirely ASCII, current AAA systems
+ sometimes perform case-insensitive matching on realms. This method
+ MAY be continued, as it has been shown to work in practice.
+
+ Many existing non-AAA systems have user identifiers that are similar
+ in format to the NAI but that are not compliant with this
+ specification. For example, they may use non-NFC form, or they may
+ have multiple "@" characters in the user identifier. Intermediate
+ nodes SHOULD normalize non-NFC identifiers to NFC, prior to looking
+ up the "utf8-realm" in the logical routing table. Intermediate nodes
+ MUST NOT modify the identifiers that they forward. The data as
+ entered by the user is inviolate.
+
+ The "utf8-realm" provisioned in the logical AAA routing table SHOULD
+ be provisioned to the proxy prior to it receiving any AAA traffic.
+ The "utf8-realm" SHOULD be supplied by the "next hop" or "home"
+ system that also supplies the routing information necessary for
+ packets to reach the next hop.
+
+
+
+
+
+
+
+DeKok Standards Track [Page 18]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ This "next hop" information may be any of, or all of, the following
+ information: IP address, port, RADIUS shared secret, TLS certificate,
+ DNS host name, or instruction to use dynamic DNS discovery (i.e.,
+ look up a record in the "utf8-realm" domain). This list is not
+ exhaustive and may be extended by future specifications.
+
+ It is RECOMMENDED to use the entirety of the "utf8-realm" for the
+ routing decisions. However, AAA systems MAY use a portion of the
+ "utf8-realm" portion, so long as that portion is a valid "utf8-realm"
+ and is handled as above. For example, routing "fred@example.com" to
+ a "com" destination is forbidden, because "com" is not a valid
+ "utf8-realm". However, routing "fred@sales.example.com" to the
+ "example.com" destination is permissible.
+
+ Another reason to forbid the use of a single label (e.g.,
+ "fred@sales") is that many non-AAA systems treat a single label as
+ being a local identifier within their realm. That is, a user logging
+ in as "fred@sales" to a domain "example.com" would be treated as if
+ the NAI was instead "fred@sales.example.com". Permitting the use of
+ a single label would mean changing the interpretation and meaning of
+ a single label, which cannot be done.
+
+3.1. Compatibility with Email Usernames
+
+ As proposed in this document, the Network Access Identifier is of the
+ form "user@realm". Please note that while the user portion of the
+ NAI is based on the "Internet Message Format" [RFC5322] "local-part"
+ portion of an email address as extended by "Internationalized Email
+ Headers" [RFC6532], it has been modified for the purposes of
+ Section 2.2. It does not permit quoted text along with "folding" or
+ "non-folding" whitespace that is commonly used in email addresses.
+ As such, the NAI is not necessarily equivalent to usernames used in
+ email.
+
+ However, it is a common practice to use email addresses as user
+ identifiers in AAA systems. The ABNF in Section 2.2 is defined to be
+ close to the "addr-spec" portion of [RFC5322] as extended by
+ [RFC6532], while still being compatible with [RFC4282].
+
+ In contrast to Section 2.5 of [RFC4282], this document states that
+ the internationalization requirements for NAIs and email addresses
+ are substantially similar. The NAI and email identifiers may be the
+ same, and both need to be entered by the user and/or the operator
+ supplying network access to that user. There is therefore good
+ reason for the internationalization requirements to be similar.
+
+
+
+
+
+
+DeKok Standards Track [Page 19]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+3.2. Compatibility with DNS
+
+ The "utf8-realm" portion of the NAI is intended to be compatible with
+ Internationalized Domain Names (IDNs) [RFC5890]. As defined above,
+ the "utf8-realm" portion as transported within an 8-bit clean
+ protocol such as RADIUS and EAP can contain any valid UTF-8
+ character. There is therefore no reason for a NAS to convert the
+ "utf8-realm" portion of an NAI into Punycode encoding form [RFC3492]
+ prior to placing the NAI into a RADIUS User-Name attribute.
+
+ The NAI does not make a distinction between A-labels and U-labels, as
+ those are terms specific to DNS. It is instead an IDNA-valid label,
+ as per the first item in Section 2.3.2.1 of [RFC5890]. As noted in
+ that section, the term "IDNA-valid label" encompasses both "A-label"
+ and "U-label".
+
+ When the realm portion of the NAI is used as the basis for name
+ resolution, it may be necessary to convert internationalized realm
+ names to Punycode [RFC3492] encoding form as described in [RFC5891].
+ As noted in Section 2 of [RFC6055], resolver Application Programming
+ Interfaces (APIs) are not necessarily DNS specific, so conversion to
+ Punycode needs to be done carefully:
+
+ Applications that convert an IDN to A-label form before calling (for
+ example) getaddrinfo() will result in name resolution failures if the
+ Punycode name is directly used in such protocols. Having libraries
+ or protocols to convert from A-labels to the encoding scheme defined
+ by the protocol (e.g., UTF-8) would require changes to APIs and/or
+ servers, which Internationalized Domain Names for Applications (IDNA)
+ was intended to avoid.
+
+ As a result, applications SHOULD NOT assume that non-ASCII names are
+ resolvable using the public DNS and blindly convert them to A-labels
+ without knowledge of what protocol will be selected by the name
+ resolution library.
+
+3.3. Realm Construction
+
+ The home realm usually appears in the "utf8-realm" portion of the
+ NAI, but in some cases a different realm can be used. This may be
+ useful, for instance, when the home realm is reachable only via
+ intermediate proxies.
+
+ Such usage may prevent interoperability unless the parties involved
+ have a mutual agreement that the usage is allowed. In particular,
+ NAIs MUST NOT use a different realm than the home realm unless the
+ sender has explicit knowledge that (a) the specified other realm is
+ available and (b) the other realm supports such usage. The sender
+
+
+
+DeKok Standards Track [Page 20]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ may determine the fulfillment of these conditions through a database,
+ dynamic discovery, or other means not specified here. Note that the
+ first condition is affected by roaming, as the availability of the
+ other realm may depend on the user's location or the desired
+ application.
+
+ The use of the home realm MUST be the default unless otherwise
+ configured.
+
+3.3.1. Historical Practices
+
+ Some AAA systems have historically used NAI modifications with
+ multiple "prefix" and "suffix" decorations to perform explicit
+ routing through multiple proxies inside of a AAA network.
+
+ In RADIUS-based environments, the use of decorated NAI is NOT
+ RECOMMENDED for the following reasons:
+
+ * Using explicit routing paths is fragile and is unresponsive to
+ changes in the network due to servers going up or down or to
+ changing business relationships.
+
+ * There is no RADIUS routing protocol, meaning that routing paths
+ have to be communicated "out of band" to all intermediate AAA
+ nodes, and also to all edge systems (e.g., supplicants) expecting
+ to obtain network access.
+
+ * Using explicit routing paths requires thousands, if not millions,
+ of edge systems to be updated with new path information when a AAA
+ routing path changes. This adds huge expense for updates that
+ would be better done at only a few AAA systems in the network.
+
+ * Manual updates to RADIUS paths are expensive, time-consuming, and
+ prone to error.
+
+ * Creating compatible formats for the NAI is difficult when locally
+ defined "prefixes" and "suffixes" conflict with similar practices
+ elsewhere in the network. These conflicts mean that connecting
+ two networks may be impossible in some cases, as there is no way
+ for packets to be routed properly in a way that meets all
+ requirements at all intermediate proxies.
+
+ * Leveraging the DNS name system for realm names establishes a
+ globally unique namespace for realms.
+
+
+
+
+
+
+
+DeKok Standards Track [Page 21]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ In summary, network practices and capabilities have changed
+ significantly since NAIs were first overloaded to define AAA routes
+ through a network. While manually managed explicit path routing was
+ once useful, the time has come for better methods to be used.
+
+ Notwithstanding the above recommendations, the above practice is
+ widely used for Diameter routing [RFC5729]. The routes described
+ there are managed automatically, for both credential provisioning and
+ routing updates. Those routes also exist within a particular
+ framework (typically 3G), where membership is controlled and system
+ behavior is standardized. There are no known issues with using
+ explicit routing in such an environment.
+
+ However, if decorated identifiers are used, such as:
+
+ homerealm.example.org!user@otherrealm.example.net
+
+ then the part before the (non-escaped) '!' MUST be a "utf8-realm" as
+ defined in the ABNF in Section 2.2. When receiving such an
+ identifier, the "otherrealm.example.net" system MUST convert the
+ identifier to "user@homerealm.example.org" before forwarding the
+ request. The forwarding system MUST then apply normal AAA routing
+ for the transaction, based on the updated identifier.
+
+3.4. Examples
+
+ Examples of valid Network Access Identifiers include the following:
+
+ bob
+ joe@example.com
+ fred@foo-9.example.com
+ jack@3rd.depts.example.com
+ fred.smith@example.com
+ fred_smith@example.com
+ fred$@example.com
+ fred=?#$&*+-/^smith@example.com
+ nancy@eng.example.net
+ eng.example.net!nancy@example.net
+ eng%nancy@example.net
+ @privatecorp.example.net
+ \(user\)@example.net
+
+ An additional valid NAI is the following -- shown here as a
+ hex string, as this document can only contain ASCII characters:
+
+ 626f 6240 ceb4 cebf ceba ceb9 cebc ceae 2e63 6f6d
+
+
+
+
+
+DeKok Standards Track [Page 22]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ Examples of invalid Network Access Identifiers include the following:
+
+ fred@example
+ fred@example_9.com
+ fred@example.net@example.net
+ fred.@example.net
+ eng:nancy@example.net
+ eng;nancy@example.net
+ (user)@example.net
+ <nancy>@example.net
+
+ One example given in [RFC4282] is still permitted by the ABNF, but it
+ is NOT RECOMMENDED because of the use of the Punycode [RFC3492]
+ encoding form for what is now a valid UTF-8 string:
+
+ alice@xn--tmonesimerkki-bfbb.example.net
+
+4. Security Considerations
+
+ Since an NAI reveals the home affiliation of a user, it may assist an
+ attacker in further probing the username space. Typically, this
+ problem is of most concern in protocols that transmit the username in
+ clear-text across the Internet, such as in RADIUS [RFC2865]
+ [RFC2866]. In order to prevent snooping of the username, protocols
+ may use confidentiality services provided by protocols transporting
+ them, such as RADIUS protected by IPsec [RFC3579] or Diameter
+ protected by TLS [RFC6733].
+
+ This specification adds the possibility of hiding the username part
+ in the NAI, by omitting it. As discussed in Section 2.4, this is
+ possible only when NAIs are used together with a separate
+ authentication method that can transfer the username in a secure
+ manner. In some cases, application-specific privacy mechanisms have
+ also been used with NAIs. For instance, some EAP methods apply
+ method-specific pseudonyms in the username part of the NAI [RFC3748].
+ While neither of these approaches can protect the realm part, their
+ advantage over transport protection is that the privacy of the
+ username is protected, even through intermediate nodes such as NASes.
+
+4.1. Correlation of Identities over Time and Protocols
+
+ The recommendations in Sections 2.7 and 2.8 for using the NAI in
+ other protocols have implications for privacy. Any attacker who is
+ capable of observing traffic containing the NAI can track the user
+ and can correlate his activity across time and across multiple
+ protocols. The authentication credentials therefore SHOULD be
+
+
+
+
+
+DeKok Standards Track [Page 23]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ transported over channels that permit private communications, or
+ multiple identifiers SHOULD be used, so that user tracking is
+ impossible.
+
+ It is RECOMMENDED that user privacy be enhanced by configuring
+ multiple identifiers for one user. These identifiers can be changed
+ over time, in order to make user tracking more difficult for a
+ malicious observer. However, provisioning and management of the
+ identifiers may be difficult to do in practice -- a likely reason why
+ multiple identifiers are rarely used today.
+
+4.2. Multiple Identifiers
+
+ Section 1.3 states that multiple identifier formats allow attackers
+ to make contradictory claims without being detected. This statement
+ deserves further discussion.
+
+ Section 2.4 discussed "inner" and "outer" identifiers in the context
+ of TTLS [RFC5281]. A close reading of that specification shows there
+ is no requirement that the inner and outer identifiers be in any way
+ related. That is, it is perfectly valid to use "@example.com" for an
+ outer identifier and "user@example.org" as an inner identifier. The
+ authentication request will then be routed to "example.com", which
+ will likely be unable to authenticate "user@example.org".
+
+ Even worse, a misconfiguration of "example.com" means that it may in
+ turn proxy the inner authentication request to the "example.org"
+ domain. Such cross-domain authentication is highly problematic, and
+ there are few good reasons to allow it.
+
+ It is therefore RECOMMENDED that systems that permit anonymous
+ "outer" identifiers require that the "inner" domain be the same as,
+ or a subdomain of, the "outer" domain. An authentication request
+ using disparate realms is a security violation, and the request
+ SHOULD be rejected.
+
+ The situation gets worse when multiple protocols are involved. The
+ TTLS protocol permits Microsoft CHAP (MS-CHAP) [RFC2433] to be
+ carried inside of the TLS tunnel. MS-CHAP defines its own
+ identifier, which is encapsulated inside of the MS-CHAP exchange.
+ That identifier is not required to be any particular format, is not
+ required to be in UTF-8, and, in practice, can be one of many unknown
+ character sets. There is no way in practice to determine which
+ character set was used for that identifier.
+
+
+
+
+
+
+
+DeKok Standards Track [Page 24]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ The result is that the "outer" EAP Identity carried by TTLS is likely
+ to not even share the same character set as the "inner" identifier
+ used by MS-CHAP. The two identifiers are entirely independent and
+ fundamentally incomparable.
+
+ Such a protocol design is NOT RECOMMENDED.
+
+5. Administration of Names
+
+ In order to avoid creating any new administrative procedures,
+ administration of the NAI realm namespace piggybacks on the
+ administration of the DNS namespace.
+
+ NAI realm names are required to be unique, and the rights to use a
+ given NAI realm for roaming purposes are obtained coincident with
+ acquiring the rights to use a particular Fully Qualified Domain Name
+ (FQDN). Those wishing to use an NAI realm name should first acquire
+ the rights to use the corresponding FQDN. Administrators MUST NOT
+ publicly use an NAI realm without first owning the corresponding
+ FQDN. Private use of unowned NAI realms within an administrative
+ domain is allowed, though it is RECOMMENDED that example names be
+ used, such as "example.com".
+
+ Note that the use of an FQDN as the realm name does not require use
+ of the DNS for location of the authentication server. While Diameter
+ [RFC6733] supports the use of DNS for location of authentication
+ servers, existing RADIUS implementations typically use proxy
+ configuration files in order to locate authentication servers within
+ a domain and perform authentication routing. The implementations
+ described in [RFC2194] did not use DNS for location of the
+ authentication server within a domain. Similarly, existing
+ implementations have not found a need for dynamic routing protocols
+ or propagation of global routing information. Note also that there
+ is no requirement that the NAI represent a valid email address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 25]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of
+ ISO 10646", STD 63, RFC 3629, November 2003,
+ <http://www.rfc-editor.org/info/rfc3629>.
+
+ [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
+ Interchange", RFC 5198, March 2008,
+ <http://www.rfc-editor.org/info/rfc5198>.
+
+ [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", STD 68, RFC 5234,
+ January 2008, <http://www.rfc-editor.org/info/rfc5234>.
+
+ [RFC5890] Klensin, J., "Internationalized Domain Names for
+ Applications (IDNA): Definitions and Document Framework",
+ RFC 5890, August 2010,
+ <http://www.rfc-editor.org/info/rfc5890>.
+
+ [RFC5891] Klensin, J., "Internationalized Domain Names in
+ Applications (IDNA): Protocol", RFC 5891, August 2010,
+ <http://www.rfc-editor.org/info/rfc5891>.
+
+ [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
+ Internationalization in the IETF", BCP 166, RFC 6365,
+ September 2011, <http://www.rfc-editor.org/info/rfc6365>.
+
+6.2. Informative References
+
+ [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang,
+ "Review of Roaming Implementations", RFC 2194,
+ September 1997, <http://www.rfc-editor.org/info/rfc2194>.
+
+ [RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco
+ Layer Two Forwarding (Protocol) "L2F"", RFC 2341,
+ May 1998, <http://www.rfc-editor.org/info/rfc2341>.
+
+ [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
+ RFC 2433, October 1998,
+ <http://www.rfc-editor.org/info/rfc2433>.
+
+
+
+
+
+DeKok Standards Track [Page 26]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
+ W., and G. Zorn, "Point-to-Point Tunneling Protocol
+ (PPTP)", RFC 2637, July 1999,
+ <http://www.rfc-editor.org/info/rfc2637>.
+
+ [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
+ G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
+ RFC 2661, August 1999,
+ <http://www.rfc-editor.org/info/rfc2661>.
+
+ [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+ "Remote Authentication Dial In User Service (RADIUS)",
+ RFC 2865, June 2000,
+ <http://www.rfc-editor.org/info/rfc2865>.
+
+ [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000,
+ <http://www.rfc-editor.org/info/rfc2866>.
+
+ [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
+ for Internationalized Domain Names in Applications
+ (IDNA)", RFC 3492, March 2003,
+ <http://www.rfc-editor.org/info/rfc3492>.
+
+ [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
+ Dial In User Service) Support For Extensible
+ Authentication Protocol (EAP)", RFC 3579, September 2003,
+ <http://www.rfc-editor.org/info/rfc3579>.
+
+ [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+ Levkowetz, Ed., "Extensible Authentication Protocol
+ (EAP)", RFC 3748, June 2004,
+ <http://www.rfc-editor.org/info/rfc3748>.
+
+ [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
+ Network Access Identifier", RFC 4282, December 2005,
+ <http://www.rfc-editor.org/info/rfc4282>.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005,
+ <http://www.rfc-editor.org/info/rfc4301>.
+
+ [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
+ Protocol Tunneled Transport Layer Security Authenticated
+ Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008,
+ <http://www.rfc-editor.org/info/rfc5281>.
+
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ October 2008, <http://www.rfc-editor.org/info/rfc5322>.
+
+
+
+DeKok Standards Track [Page 27]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ [RFC5335] Yang, A., Ed., "Internationalized Email Headers",
+ RFC 5335, September 2008,
+ <http://www.rfc-editor.org/info/rfc5335>.
+
+ [RFC5729] Korhonen, J., Ed., Jones, M., Morand, L., and T. Tsou,
+ "Clarifications on the Routing of Diameter Requests Based
+ on the Username and the Realm", RFC 5729, December 2009,
+ <http://www.rfc-editor.org/info/rfc5729>.
+
+ [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
+ Encodings for Internationalized Domain Names", RFC 6055,
+ February 2011, <http://www.rfc-editor.org/info/rfc6055>.
+
+ [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
+ Email Headers", RFC 6532, February 2012,
+ <http://www.rfc-editor.org/info/rfc6532>.
+
+ [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
+ Ed., "Diameter Base Protocol", RFC 6733, October 2012,
+ <http://www.rfc-editor.org/info/rfc6733>.
+
+ [RFC6912] Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman,
+ "Principles for Unicode Code Point Inclusion in Labels in
+ the DNS", RFC 6912, April 2013,
+ <http://www.rfc-editor.org/info/rfc6912>.
+
+ [EDUROAM] "eduroam (EDUcation ROAMing)", <http://eduroam.org>.
+
+ [3GPP] 3GPP, "Numbering, addressing and Identification", 3GPP TS
+ 23.003, Release 12, July 2014,
+ <ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 28]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+Appendix A. Changes from RFC 4282
+
+ This document contains the following updates with respect to the
+ previous NAI definition in RFC 4282 [RFC4282]:
+
+ * The formal syntax in Section 2.1 has been updated to forbid
+ non-UTF-8 characters (e.g., characters with the "high bit" set).
+
+ * The formal syntax in Section 2.1 of [RFC4282] has been updated to
+ allow UTF-8 in the "realm" portion of the NAI.
+
+ * The formal syntax in Section 2.1 of [RFC4282] applied to the NAI
+ after it was "internationalized" via the ToAscii function. The
+ contents of the NAI before it was "internationalized" were left
+ indeterminate. This document updates the formal syntax to define
+ an internationalized form of the NAI and forbids the use of the
+ ToAscii function for NAI "internationalization".
+
+ * The grammar for the user and realm portion is based on a
+ combination of the "nai" defined in Section 2.1 of [RFC4282] and
+ the "utf8-addr-spec" defined in Section 4.4 of [RFC5335].
+
+ * All use of the ToAscii function has been moved to normal
+ requirements on DNS implementations when realms are used as the
+ basis for DNS lookups. This involves no changes to the existing
+ DNS infrastructure.
+
+ * The discussions on internationalized character sets in Section 2.4
+ of [RFC4282] have been updated. The suggestion to use the ToAscii
+ function for realm comparisons has been removed. No AAA system
+ has implemented these suggestions, so this change should have no
+ operational impact.
+
+ * The "Routing inside of AAA Systems" section is new in this
+ document. The concept of a "local AAA routing table" is also new,
+ although it accurately describes the functionality of widespread
+ implementations.
+
+ * The "Compatibility with EMail Usernames" and "Compatibility with
+ DNS" sections have been revised and updated. The Punycode
+ transformation is suggested to be used only when a realm name is
+ used for DNS lookups, and even then the function is only used by a
+ resolving API on the local system, and even then it is recommended
+ that only the home network perform this conversion.
+
+
+
+
+
+
+
+DeKok Standards Track [Page 29]
+\f
+RFC 7542 The Network Access Identifier May 2015
+
+
+ * The "Realm Construction" section has been updated to note that
+ editing of the NAI is NOT RECOMMENDED.
+
+ * The "Examples" section has been updated to remove the instance of
+ the IDN being converted to ASCII. This behavior is now forbidden.
+
+Acknowledgments
+
+ The initial text for this document was [RFC4282], which was then
+ heavily edited. The original authors of [RFC4282] were Bernard
+ Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen.
+
+Author's Address
+
+ Alan DeKok
+ The FreeRADIUS Server Project
+
+ EMail: aland@freeradius.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 30]
+\f
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) X. Li
+Request for Comments: 7599 C. Bao
+Category: Standards Track Tsinghua University
+ISSN: 2070-1721 W. Dec, Ed.
+ O. Troan
+ Cisco Systems
+ S. Matsushima
+ SoftBank Telecom
+ T. Murakami
+ IP Infusion
+ July 2015
+
+
+ Mapping of Address and Port using Translation (MAP-T)
+
+Abstract
+
+ This document specifies the solution architecture based on "Mapping
+ of Address and Port" stateless IPv6-IPv4 Network Address Translation
+ (NAT64) for providing shared or non-shared IPv4 address connectivity
+ to and across an IPv6 network.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7599.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 1]
+\f
+RFC 7599 MAP-T July 2015
+
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 2]
+\f
+RFC 7599 MAP-T July 2015
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Conventions .....................................................4
+ 3. Terminology .....................................................5
+ 4. Architecture ....................................................6
+ 5. Mapping Rules ...................................................8
+ 5.1. Destinations outside the MAP Domain ........................8
+ 6. The IPv6 Interface Identifier ...................................9
+ 7. MAP-T Configuration ............................................10
+ 7.1. MAP CE ....................................................10
+ 7.2. MAP BR ....................................................11
+ 8. MAP-T Packet Forwarding ........................................11
+ 8.1. IPv4 to IPv6 at the CE ....................................11
+ 8.2. IPv6 to IPv4 at the CE ....................................12
+ 8.3. IPv6 to IPv4 at the BR ....................................12
+ 8.4. IPv4 to IPv6 at the BR ....................................13
+ 9. ICMP Handling ..................................................13
+ 10. Fragmentation and Path MTU Discovery ..........................14
+ 10.1. Fragmentation in the MAP Domain ..........................14
+ 10.2. Receiving IPv4 Fragments on the MAP Domain Borders .......14
+ 10.3. Sending IPv4 Fragments to the Outside ....................14
+ 11. NAT44 Considerations ..........................................15
+ 12. Usage Considerations ..........................................15
+ 12.1. EA-Bit Length 0 ..........................................15
+ 12.2. Mesh and Hub-and-Spoke Modes .............................15
+ 12.3. Communication with IPv6 Servers in the MAP-T Domain ......15
+ 12.4. Compatibility with Other NAT64 Solutions .................16
+ 13. Security Considerations .......................................16
+ 14. References ....................................................17
+ 14.1. Normative References .....................................17
+ 14.2. Informative References ...................................18
+ Appendix A. Examples of MAP-T Translation .........................21
+ Appendix B. Port-Mapping Algorithm ................................24
+ Acknowledgements ..................................................25
+ Contributors ......................................................25
+ Authors' Addresses ................................................26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 3]
+\f
+RFC 7599 MAP-T July 2015
+
+
+1. Introduction
+
+ Experiences from initial service provider IPv6 network deployments,
+ such as [RFC6219], indicate that successful transition to IPv6 can
+ happen while supporting legacy IPv4 users without a full end-to-end
+ dual-IP-stack deployment. However, due to public IPv4 address
+ exhaustion, this requires an IPv6 technology that supports IPv4 users
+ utilizing shared IPv4 addressing, while also allowing the network
+ operator to optimize their operations around IPv6 network practices.
+ The use of double NAT64 translation-based solutions is an optimal way
+ to address these requirements, especially in combination with
+ stateless translation techniques that minimize operational challenges
+ outlined in [Solutions-4v6].
+
+ The Mapping of Address and Port using Translation (MAP-T)
+ architecture specified in this document is such a double stateless
+ NAT64-based solution. It builds on existing stateless NAT64
+ techniques specified in [RFC6145], along with the stateless
+ algorithmic address and transport-layer port-mapping scheme defined
+ in the Mapping of Address and Port with Encapsulation (MAP-E)
+ specification [RFC7597]. The MAP-T solution differs from MAP-E in
+ that MAP-T uses IPv4-IPv6 translation, rather than encapsulation, as
+ the form of IPv6 domain transport. The translation mode is
+ considered advantageous in scenarios where the encapsulation
+ overhead, or IPv6 operational practices (e.g., the use of IPv6-only
+ servers, or reliance on IPv6 + protocol headers for traffic
+ classification) rule out encapsulation. These scenarios are
+ presented in [MAP-T-Use-Cases].
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 4]
+\f
+RFC 7599 MAP-T July 2015
+
+
+3. Terminology
+
+ MAP-T: Mapping of Address and Port using
+ Translation.
+
+ MAP Customer Edge (CE): A device functioning as a Customer Edge
+ router in a MAP deployment. A typical MAP CE
+ adopting MAP Rules will serve a residential
+ site with one WAN-side IPv6-addressed
+ interface and one or more LAN-side interfaces
+ addressed using private IPv4 addressing.
+
+ MAP Border Relay (BR): A MAP-enabled router managed by the service
+ provider at the edge of a MAP domain. A BR
+ has at least an IPv6-enabled interface and an
+ IPv4 interface connected to the native IPv4
+ network. A MAP BR may also be referred to as
+ simply a "BR" within the context of MAP.
+
+ MAP domain: One or more MAP CEs and BRs connected by
+ means of an IPv6 network and sharing a common
+ set of MAP Rules. A service provider may
+ deploy a single MAP domain or may utilize
+ multiple MAP domains.
+
+ MAP Rule: A set of parameters describing the mapping
+ between an IPv4 prefix, IPv4 address, or
+ shared IPv4 address and an IPv6 prefix or
+ address. Each MAP domain uses a different
+ mapping rule set.
+
+ MAP rule set: A rule set is composed of all the MAP Rules
+ communicated to a device that are intended to
+ determine the device's IP+port mapping and
+ forwarding operations. The MAP rule set is
+ interchangeably referred to in this document
+ as a MAP rule table or as simply a "rule
+ table". Two specific types of rules -- the
+ Basic Mapping Rule (BMR) and the Forwarding
+ Mapping Rule (FMR) -- are defined in
+ Section 5 of [RFC7597]. The Default Mapping
+ Rule (DMR) is defined in this document.
+
+ MAP rule table: See MAP rule set.
+
+ MAP node: A device that implements MAP.
+
+
+
+
+
+Li, et al. Standards Track [Page 5]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ Port set: Each node has a separate part of the
+ transport-layer port space; this is denoted
+ as a port set.
+
+ Port Set ID (PSID): Algorithmically identifies a set of ports
+ exclusively assigned to a CE.
+
+ Shared IPv4 address: An IPv4 address that is shared among multiple
+ CEs. Only ports that belong to the assigned
+ port set can be used for communication. Also
+ known as a port-restricted IPv4 address.
+
+ End-user IPv6 prefix: The IPv6 prefix assigned to an End-user CE by
+ means other than MAP itself, e.g.,
+ provisioned using DHCPv6 Prefix Delegation
+ (PD) [RFC3633], assigned via Stateless
+ Address Autoconfiguration (SLAAC) [RFC4862],
+ or configured manually. It is unique for
+ each CE.
+
+ MAP IPv6 address: The IPv6 address used to reach the MAP
+ function of a CE from other CEs and from BRs.
+
+ Rule IPv6 prefix: An IPv6 prefix assigned by a service provider
+ for a MAP Rule.
+
+ Rule IPv4 prefix: An IPv4 prefix assigned by a service provider
+ for a MAP Rule.
+
+ Embedded Address (EA) bits:
+ The IPv4 EA-bits in the IPv6 address identify
+ an IPv4 prefix/address (or part thereof) or a
+ shared IPv4 address (or part thereof) and a
+ Port Set Identifier.
+
+4. Architecture
+
+ Figure 1 depicts the overall MAP-T architecture, which sees any
+ number of privately addressed IPv4 users (N and M) connected by means
+ of MAP-T CEs to an IPv6 network that is equipped with one or more
+ MAP-T BRs. CEs and BRs that share MAP configuration parameters,
+ referred to as "MAP Rules", form a MAP-T domain.
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 6]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ Functionally, the MAP-T CE and BR utilize and extend some
+ well-established technology building blocks to allow the IPv4 users
+ to correspond with nodes on the public IPv4 network or on the IPv6
+ network as follows:
+
+ o A (NAT44) Network Address and Port Translation (NAPT) [RFC2663]
+ function on a MAP CE is extended with support for restricting the
+ allowable TCP/UDP ports for a given IPv4 address. The IPv4
+ address and port range used are determined by the MAP provisioning
+ process and identical to MAP-E [RFC7597].
+
+ o A stateless NAT64 function [RFC6145] is extended to allow
+ stateless mapping of IPv4 and transport-layer port ranges to the
+ IPv6 address space.
+
+ User N
+ Private IPv4
+ | Network
+ |
+ O--+---------------O
+ | | MAP-T CE |
+ | +-----+--------+ |
+ | NAPT44| MAP-T | |
+ | +-----+ | +-._ ,-------. .------.
+ | +--------+ | ,-' `-. ,-' `-.
+ O------------------O / \ O---------O / Public \
+ / IPv6-only \ | MAP-T |/ IPv4 \
+ ( Network --+ Border +- Network )
+ \ / | Relay |\ /
+ O------------------O \ / O---------O \ /
+ | MAP-T CE | ;". ,-' `-. ,-'
+ | +-----+--------+ | ," `----+--' ------'
+ | NAPT44| MAP-T | |, |
+ | +-----+ | + IPv6 node(s)
+ | | +--------+ | (with IPv4-embedded IPv6 address)
+ O---+--------------O
+ |
+ User M
+ Private IPv4
+ Network
+
+ Figure 1: MAP-T Architecture
+
+ Each MAP-T CE is assigned with a regular IPv6 prefix from the
+ operator's IPv6 network. This, in conjunction with MAP domain
+ configuration settings and the use of the MAP procedures, allows the
+ computation of a MAP IPv6 address and a corresponding IPv4 address.
+ To allow for IPv4 address sharing, the CE may also have to be
+
+
+
+Li, et al. Standards Track [Page 7]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ configured with a TCP/UDP port range that is identified by means of a
+ MAP Port Set Identifier (PSID) value. Each CE is responsible for
+ forwarding traffic between a given user's private IPv4 address space
+ and the MAP domain's IPv6 address space. The IPv4-IPv6 adaptation
+ uses stateless NAT64, in conjunction with the MAP algorithm for
+ address computation.
+
+ The MAP-T BR connects one or more MAP-T domains to external IPv4
+ networks using stateless NAT64 as extended by the MAP-T behavior
+ described in this document.
+
+ In contrast to MAP-E, NAT64 technology is used in the architecture
+ for two purposes. First, it is intended to diminish encapsulation
+ overhead and allow IPv4 and IPv6 traffic to be treated as similarly
+ as possible. Second, it is intended to allow IPv4-only nodes to
+ correspond directly with IPv6 nodes in the MAP-T domain that have
+ IPv4-embedded IPv6 addresses as per [RFC6052].
+
+ The MAP-T architecture is based on the following key properties:
+
+ 1. Algorithmic IPv4-IPv6 address mapping codified as MAP Rules, as
+ described in Section 5
+
+ 2. A MAP IPv6 address identifier, as described in Section 6
+
+ 3. MAP-T IPv4-IPv6 forwarding behavior, as described in Section 8
+
+5. Mapping Rules
+
+ The MAP-T algorithmic mapping rules are identical to those in
+ Section 5 of the MAP-E specification [RFC7597], with the following
+ exception: the forwarding of traffic to and from IPv4 destinations
+ outside a MAP-T domain is to be performed as described in this
+ document, instead of Section 5.4 of the MAP-E specification.
+
+5.1. Destinations outside the MAP Domain
+
+ IPv4 traffic sent by MAP nodes that are all within one MAP domain is
+ translated to IPv6, with the sender's MAP IPv6 address, derived via
+ the Basic Mapping Rule (BMR), as the IPv6 source address and the
+ recipient's MAP IPv6 address, derived via the Forwarding Mapping Rule
+ (FMR), as the IPv6 destination address.
+
+ IPv4-addressed destinations outside of the MAP domain are represented
+ by means of IPv4-embedded IPv6 addresses as per [RFC6052], using the
+ BR's IPv6 prefix. For a CE sending traffic to any such destination,
+ the source address of the IPv6 packet will be that of the CE's MAP
+ IPv6 address, and the destination IPv6 address will be the
+
+
+
+Li, et al. Standards Track [Page 8]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ destination IPv4-embedded IPv6 address. This address mapping is said
+ to be following the MAP-T Default Mapping Rule (DMR) and is defined
+ in terms of the IPv6 prefix advertised by one or more BRs, which
+ provide external connectivity. A typical MAP-T CE will install an
+ IPv4 default route using this rule. A BR will use this rule when
+ translating all outside IPv4 source addresses to the IPv6 MAP domain.
+
+ The DMR IPv6 prefix length SHOULD be 64 bits long by default and in
+ any case MUST NOT exceed 96 bits. The mapping of the IPv4
+ destination behind the IPv6 prefix will by default follow the /64
+ rule as per [RFC6052]. Any trailing bits after the IPv4 address are
+ set to 0x0.
+
+6. The IPv6 Interface Identifier
+
+ The interface identifier format of a MAP-T node is the same as the
+ format described in Section 6 of [RFC7597]. The format diagram is
+ provided here for convenience:
+
+ | 128-n-o-s bits |
+ | 16 bits| 32 bits | 16 bits|
+ +--------+----------------+--------+
+ | 0 | IPv4 address | PSID |
+ +--------+----------------+--------+
+
+ Figure 2: IPv6 Interface Identifier
+
+ In the case of an IPv4 prefix, the IPv4 address field is right-padded
+ with zeros up to 32 bits. The PSID is left-padded with zeros to
+ create a 16-bit field. For an IPv4 prefix or a complete IPv4
+ address, the PSID field is zero.
+
+ If the End-user IPv6 prefix length is larger than 64, the most
+ significant parts of the interface identifier are overwritten by the
+ prefix.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 9]
+\f
+RFC 7599 MAP-T July 2015
+
+
+7. MAP-T Configuration
+
+ For a given MAP domain, the BR and CE MUST be configured with the
+ following MAP parameters. The values for these parameters are
+ identical for all CEs and BRs within a given MAP-T domain.
+
+ o The Basic Mapping Rule and, optionally, the Forwarding Mapping
+ Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and
+ Length of embedded address bits
+
+ o Use of hub-and-spoke mode or Mesh mode (if all traffic should be
+ sent to the BR, or if direct CE-to-CE correspondence should be
+ supported)
+
+ o Use of IPv4-IPv6 translation (MAP-T)
+
+ o The BR's IPv6 prefix used in the DMR
+
+7.1. MAP CE
+
+ For a given MAP domain, the MAP configuration parameters are the same
+ across all CEs within that domain. These values may be conveyed and
+ configured on the CEs using a variety of methods, including DHCPv6,
+ the Broadband Forum's "TR-69" Residential Gateway management
+ interface [TR069], the Network Configuration Protocol (NETCONF), or
+ manual configuration. This document does not prescribe any of these
+ methods but recommends that a MAP CE SHOULD implement DHCPv6 options
+ as per [RFC7598]. Other configuration and management methods may use
+ the data model described by this option for consistency and
+ convenience of implementation on CEs that support multiple
+ configuration methods.
+
+ Besides the MAP configuration parameters, a CE requires an IPv6
+ prefix to be assigned to the CE. This End-user IPv6 prefix is
+ configured as part of obtaining IPv6 Internet access and is acquired
+ using standard IPv6 means applicable in the network where the CE is
+ located.
+
+ The MAP provisioning parameters, and hence the IPv4 service itself,
+ are tied to the End-user IPv6 prefix; thus, the MAP service is also
+ tied to this in terms of authorization, accounting, etc.
+
+ A single MAP CE MAY be connected to more than one MAP domain, just as
+ any router may have more than one IPv4-enabled service-provider-
+ facing interface and more than one set of associated addresses
+ assigned by DHCPv6. Each domain within which a given CE operates
+
+
+
+
+
+Li, et al. Standards Track [Page 10]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ would require its own set of MAP configuration elements and would
+ generate its own IPv4 address. Each MAP domain requires a distinct
+ End-user IPv6 prefix.
+
+7.2. MAP BR
+
+ The MAP BR MUST be configured with the same MAP elements as the MAP
+ CEs operating within the same domain.
+
+ For increased reliability and load balancing, the BR IPv6 prefix MAY
+ be shared across a given MAP domain. As MAP is stateless, any BR may
+ be used for forwarding to/from the domain at any time.
+
+ Since MAP uses provider address space, no specific IPv6 or IPv4
+ routes need to be advertised externally outside the service
+ provider's network for MAP to operate. However, the BR prefix needs
+ to be advertised in the service provider's IGP.
+
+8. MAP-T Packet Forwarding
+
+ The end-to-end packet flow in MAP-T involves an IPv4 or IPv6 packet
+ being forwarded by a CE or BR in one of two directions for each such
+ case. This section presents a conceptual view of the operations
+ involved in such forwarding.
+
+8.1. IPv4 to IPv6 at the CE
+
+ A MAP-T CE receiving IPv4 packets SHOULD perform NAPT44 processing
+ and create any necessary NAPT44 bindings. The source address and
+ source port range of packets resulting from the NAPT44 processing
+ MUST correspond to the source IPv4 address and source transport port
+ range assigned to the CE by means of the MAP Basic Mapping Rule
+ (BMR).
+
+ The IPv4 packet is subject to a longest IPv4 destination address +
+ port match MAP Rule selection, which then determines the parameters
+ for the subsequent NAT64 operation. By default, all traffic is
+ matched to the DMR and is subject to the stateless NAT64 operation
+ using the DMR parameters for NAT64 (Section 5.1). Packets that are
+ matched to (optional) Forwarding Mapping Rules (FMRs) are subject to
+ the stateless NAT64 operation using the FMR parameters (Section 5)
+ for the MAP algorithm. In all cases, the CE's MAP IPv6 address
+ (Section 6) is used as a source address.
+
+ A MAP-T CE MUST support a Default Mapping Rule and SHOULD support one
+ or more Forwarding Mapping Rules.
+
+
+
+
+
+Li, et al. Standards Track [Page 11]
+\f
+RFC 7599 MAP-T July 2015
+
+
+8.2. IPv6 to IPv4 at the CE
+
+ A MAP-T CE receiving an IPv6 packet performs its regular IPv6
+ operations (filtering, pre-routing, etc.). Only packets that are
+ addressed to the CE's MAP-T IPv6 addresses, and with source addresses
+ matching the IPv6 MAP Rule prefixes of a DMR or FMR, are processed by
+ the MAP-T CE, with the DMR or FMR being selected based on a longest
+ match. The CE MUST check that each MAP-T received packet's
+ transport-layer destination port number is in the range allowed for
+ by the CE's MAP BMR configuration. The CE MUST silently drop any
+ nonconforming packet and increment an appropriate counter. When
+ receiving a packet whose source IP address longest matches an FMR
+ prefix, the CE MUST perform a check of consistency of the source
+ address against the allowed values as per the derived allocated
+ source port range. If the source port number of a packet is found to
+ be outside the allocated range, the CE MUST drop the packet and
+ SHOULD respond with an ICMPv6 "Destination Unreachable, source
+ address failed ingress/egress policy" (Type 1, Code 5).
+
+ For each MAP-T processed packet, the CE's NAT64 function MUST compute
+ an IPv4 source and destination address. The IPv4 destination address
+ is computed by extracting relevant information from the IPv6
+ destination and the information stored in the BMR as per Section 5.
+ The IPv4 source address is formed by classifying a packet's source as
+ longest matching a DMR or FMR rule prefix, and then using the
+ respective rule parameters for the NAT64 operation.
+
+ The resulting IPv4 packet is then forwarded to the CE's NAPT44
+ function, where the destination IPv4 address and port number MUST be
+ mapped to their original value before being forwarded according to
+ the CE's regular IPv4 rules. When the NAPT44 function is not
+ enabled, by virtue of MAP configuration, the traffic from the
+ stateless NAT64 function is directly forwarded according to the CE's
+ IPv4 rules.
+
+8.3. IPv6 to IPv4 at the BR
+
+ A MAP-T BR receiving an IPv6 packet MUST select a matching MAP Rule
+ based on a longest address match of the packet's source address
+ against the MAP Rules present on the BR. In combination with the
+ Port Set ID derived from the packet's source IPv6 address, the
+ selected MAP Rule allows the BR to verify that the CE is using its
+ allowed address and port range. Thus, the BR MUST perform a
+ validation of the consistency of the source against the allowed
+ values from the identified port range. If the packet's source port
+ number is found to be outside the range allowed, the BR MUST drop the
+
+
+
+
+
+Li, et al. Standards Track [Page 12]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ packet and increment a counter to indicate the event. The BR SHOULD
+ also respond with an ICMPv6 "Destination Unreachable, source address
+ failed ingress/egress policy" (Type 1, Code 5).
+
+ When constructing the IPv4 packet, the BR MUST derive the source and
+ destination IPv4 addresses as per Section 5 of this document and
+ translate the IPv6-to-IPv4 headers as per [RFC6145]. The resulting
+ IPv4 packet is then passed to regular IPv4 forwarding.
+
+8.4. IPv4 to IPv6 at the BR
+
+ A MAP-T BR receiving IPv4 packets uses a longest match IPv4 +
+ transport-layer port lookup to identify the target MAP-T domain and
+ select the FMR and DMR rules. The MAP-T BR MUST then compute and
+ apply the IPv6 destination addresses from the IPv4 destination
+ address and port as per the selected FMR. The MAP-T BR MUST also
+ compute and apply the IPv6 source addresses from the IPv4 source
+ address as per Section 5.1 (i.e., using the IPv4 source and the BR's
+ IPv6 prefix, it forms an IPv6-embedded IPv4 address). The generic
+ IPv4-to-IPv6 header translation procedures outlined in [RFC6145]
+ apply throughout. The resulting IPv6 packets are then passed to
+ regular IPv6 forwarding.
+
+ Note that the operation of a BR, when forwarding to/from MAP-T
+ domains that are defined without IPv4 address sharing, is the same as
+ that of stateless NAT64 IPv4/IPv6 translation.
+
+9. ICMP Handling
+
+ MAP-T CEs and BRs MUST follow ICMP/ICMPv6 translation as per
+ [RFC6145]; however, additional behavior is also required due to the
+ presence of NAPT44. Unlike TCP and UDP, which provide two transport-
+ protocol port fields to represent both source and destination, the
+ ICMP/ICMPv6 [RFC792] [RFC4443] Query message header has only one ID
+ field, which needs to be used to identify a sending IPv4 host. When
+ receiving IPv4 ICMP messages, the MAP-T CE MUST rewrite the ID field
+ to a port value derived from the CE's Port Set ID.
+
+ A MAP-T BR receiving an IPv4 ICMP packet that contains an ID field
+ that is bound for a shared address in the MAP-T domain SHOULD use the
+ ID value as a substitute for the destination port in determining the
+ IPv6 destination address. In all other cases, the MAP-T BR MUST
+ derive the destination IPv6 address by simply mapping the destination
+ IPv4 address without additional port information.
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 13]
+\f
+RFC 7599 MAP-T July 2015
+
+
+10. Fragmentation and Path MTU Discovery
+
+ Due to the different sizes of the IPv4 and IPv6 headers, handling the
+ maximum packet size is relevant for the operation of any system
+ connecting the two address families. There are three mechanisms to
+ handle this issue: Path MTU Discovery (PMTUD), fragmentation, and
+ transport-layer negotiation such as the TCP Maximum Segment Size
+ (MSS) option [RFC879]. MAP can use all three mechanisms to deal with
+ different cases.
+
+ Note: The NAT64 [RFC6145] mechanism is not lossless. When
+ IPv4-originated communication traverses a double NAT64 function
+ (a.k.a. NAT464), any IPv4-originated ICMP-independent Path MTU
+ Discovery, as specified in [RFC4821], ceases to be entirely reliable.
+ This is because the DF=1/MF=1 combination as defined in [RFC4821]
+ results in DF=0/MF=1 after a double NAT64 translation.
+
+10.1. Fragmentation in the MAP Domain
+
+ Translating an IPv4 packet to carry it across the MAP domain will
+ increase its size (typically by 20 bytes). The MTU in the MAP domain
+ should be well managed, and the IPv6 MTU on the CE WAN-side interface
+ SHOULD be configured so that no fragmentation occurs within the
+ boundary of the MAP domain.
+
+ Fragmentation in MAP-T domains SHOULD be handled as described in
+ Sections 4 and 5 of [RFC6145].
+
+10.2. Receiving IPv4 Fragments on the MAP Domain Borders
+
+ The forwarding of an IPv4 packet received from outside of the MAP
+ domain requires the IPv4 destination address and the transport-
+ protocol destination port. The transport-protocol information is
+ only available in the first fragment received. As described in
+ Section 5.3.3 of [RFC6346], a MAP node receiving an IPv4 fragmented
+ packet from outside SHOULD reassemble the packet before sending the
+ packet onto the MAP domain. If the first packet received contains
+ the transport-protocol information, it is possible to optimize this
+ behavior by using a cache and forwarding the fragments unchanged. A
+ description of such a caching algorithm is outside the scope of this
+ document.
+
+10.3. Sending IPv4 Fragments to the Outside
+
+ Two IPv4 hosts behind two different MAP CEs with the same IPv4
+ address sending fragments to an IPv4 destination host outside the
+ domain may happen to use the same IPv4 fragmentation identifier,
+ resulting in incorrect reassembly of the fragments at the destination
+
+
+
+Li, et al. Standards Track [Page 14]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ host. Given that the IPv4 fragmentation identifier is a 16-bit
+ field, it can be used similarly to port ranges. Thus, a MAP CE
+ SHOULD rewrite the IPv4 fragmentation identifier to a value
+ equivalent to a port of its allocated port set.
+
+11. NAT44 Considerations
+
+ The NAT44 implemented in the MAP CE SHOULD conform to the behavior
+ and best current practices documented in [RFC4787], [RFC5508], and
+ [RFC5382]. In MAP address-sharing mode (determined by the MAP
+ domain / rule configuration parameters), the operation of the NAT44
+ MUST be restricted to the available port numbers derived via the
+ Basic Mapping Rule.
+
+12. Usage Considerations
+
+12.1. EA-Bit Length 0
+
+ The MAP solution supports the use and configuration of domains where
+ a BMR expresses an EA-bit length of 0. This results in independence
+ between the IPv6 prefix assigned to the CE and the IPv4 address
+ and/or port range used by MAP. The k-bits of PSID information may in
+ this case be derived from the BMR.
+
+ The constraint imposed is that each such MAP domain be composed of
+ just one MAP CE that has a predetermined IPv6 end-user prefix. The
+ BR would be configured with an FMR for each such Customer Premises
+ Equipment (CPE), where the rule would uniquely associate the IPv4
+ address + optional PSID and the IPv6 prefix of that given CE.
+
+12.2. Mesh and Hub-and-Spoke Modes
+
+ The hub-and-spoke mode of communication, whereby all traffic sent by
+ a MAP-T CE is forwarded via a BR, and the Mesh mode, whereby a CE is
+ directly able to forward traffic to another CE, are governed by the
+ activation of Forwarding Mapping Rules that cover the IPv4-prefix
+ destination and port-index range. By default, a MAP CE configured
+ only with a BMR, as per this specification, will use it to configure
+ its IPv4 parameters and IPv6 MAP address without enabling Mesh mode.
+
+12.3. Communication with IPv6 Servers in the MAP-T Domain
+
+ By default, MAP-T allows communication between both IPv4-only and any
+ IPv6-enabled devices, as well as with native IPv6-only servers,
+ provided that the servers are configured with an IPv4-mapped IPv6
+ address. This address could be part of the IPv6 prefix used by the
+ DMR in the MAP-T domain. Such IPv6 servers (e.g., an HTTP server or
+ a web content cache device) are thus able to serve IPv6 users and
+
+
+
+Li, et al. Standards Track [Page 15]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ IPv4-only users alike, utilizing IPv6. Any such IPv6-only servers
+ SHOULD have both A and AAAA records in DNS. DNS64 [RFC6147] will be
+ required only when IPv6 servers in the MAP-T domain are themselves
+ expected to initiate communication to external IPv4-only hosts.
+
+12.4. Compatibility with Other NAT64 Solutions
+
+ The MAP-T CE's NAT64 function is by default compatible for use with
+ [RFC6146] stateful NAT64 devices that are placed in the operator's
+ network. In such a case, the MAP-T CE's DMR prefix is configured to
+ correspond to the NAT64 device prefix. This in effect allows the use
+ of MAP-T CEs in environments that need to perform statistical
+ multiplexing of IPv4 addresses, while utilizing stateful NAT64
+ devices, and can take the role of a customer-side translator (CLAT)
+ as defined in [RFC6877].
+
+13. Security Considerations
+
+ Spoofing attacks: With consistency checks between IPv4 and IPv6
+ sources that are performed on IPv4/IPv6 packets received by MAP
+ nodes, MAP does not introduce any new opportunity for spoofing
+ attacks that would not already exist in IPv6.
+
+ Denial-of-service attacks: In MAP domains where IPv4 addresses are
+ shared, the fact that IPv4 datagram reassembly may be necessary
+ introduces an opportunity for DoS attacks. This is inherent in
+ address sharing and is common with other address-sharing
+ approaches such as Dual-Stack Lite (DS-Lite) and NAT64/DNS64. The
+ best protection against such attacks is to accelerate IPv6 support
+ in both clients and servers.
+
+ Routing loop attacks: Routing loop attacks may exist in some
+ "automatic tunneling" scenarios and are documented in [RFC6324].
+ They cannot exist with MAP because each BR checks that the IPv6
+ source address of a received IPv6 packet is a CE address based on
+ the Forwarding Mapping Rule.
+
+ Attacks facilitated by restricted port set: From hosts that are not
+ subject to ingress filtering [RFC2827], an attacker can inject
+ spoofed packets during ongoing transport connections [RFC4953]
+ [RFC5961] [RFC6056]. The attacks depend on guessing which ports
+ are currently used by target hosts. Using an unrestricted port
+ set is preferable, i.e., using native IPv6 connections that are
+ not subject to MAP port-range restrictions. To minimize these
+ types of attacks when using a restricted port set, the MAP CE's
+ NAT44 filtering behavior SHOULD be "Address-Dependent Filtering"
+ as described in Section 5 of [RFC4787]. Furthermore, the MAP CEs
+ SHOULD use a DNS transport proxy function to handle DNS traffic
+
+
+
+Li, et al. Standards Track [Page 16]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ and source such traffic from IPv6 interfaces not assigned to
+ MAP-T. Practicalities of these methods are discussed in
+ Section 5.9 of [Stateless-4Via6].
+
+ ICMP Flooding: Given the necessity to process and translate ICMP and
+ ICMPv6 messages by the BR and CE nodes, a foreseeable attack
+ vector is that of a flood of such messages leading to a saturation
+ of the node's ICMP computing resources. This attack vector is not
+ specific to MAP, and its mitigation lies in a combination of
+ policing the rate of ICMP messages, policing the rate at which
+ such messages can get processed by the MAP nodes, and of course
+ identifying and blocking off the source(s) of such traffic.
+
+ [RFC6269] outlines general issues with IPv4 address sharing.
+
+14. References
+
+14.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+ Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+ DOI 10.17487/RFC6052, October 2010,
+ <http://www.rfc-editor.org/info/rfc6052>.
+
+ [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
+ Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
+ <http://www.rfc-editor.org/info/rfc6145>.
+
+ [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to
+ the IPv4 Address Shortage", RFC 6346,
+ DOI 10.17487/RFC6346, August 2011,
+ <http://www.rfc-editor.org/info/rfc6346>.
+
+ [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
+ Murakami, T., and T. Taylor, Ed., "Mapping of Address and
+ Port with Encapsulation (MAP-E)", RFC 7597,
+ DOI 10.17487/RFC7597, July 2015,
+ <http://www.rfc-editor.org/info/rfc7597>.
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 17]
+\f
+RFC 7599 MAP-T July 2015
+
+
+14.2. Informative References
+
+ [MAP-T-Use-Cases]
+ Maglione, R., Ed., Dec, W., Leung, I., and E. Mallette,
+ "Use cases for MAP-T", Work in Progress,
+ draft-maglione-softwire-map-t-scenarios-05, October 2014.
+
+ [RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
+ RFC 792, DOI 10.17487/RFC0792, September 1981,
+ <http://www.rfc-editor.org/info/rfc792>.
+
+ [RFC879] Postel, J., "The TCP Maximum Segment Size and Related
+ Topics", RFC 879, DOI 10.17487/RFC0879, November 1983,
+ <http://www.rfc-editor.org/info/rfc879>.
+
+ [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
+ Translator (NAT) Terminology and Considerations",
+ RFC 2663, DOI 10.17487/RFC2663, August 1999,
+ <http://www.rfc-editor.org/info/rfc2663>.
+
+ [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
+ Defeating Denial of Service Attacks which employ IP Source
+ Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
+ May 2000, <http://www.rfc-editor.org/info/rfc2827>.
+
+ [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
+ Host Configuration Protocol (DHCP) version 6", RFC 3633,
+ DOI 10.17487/RFC3633, December 2003,
+ <http://www.rfc-editor.org/info/rfc3633>.
+
+ [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+ Control Message Protocol (ICMPv6) for the Internet
+ Protocol Version 6 (IPv6) Specification", RFC 4443,
+ DOI 10.17487/RFC4443, March 2006,
+ <http://www.rfc-editor.org/info/rfc4443>.
+
+ [RFC4787] Audet, F., Ed., and C. Jennings, "Network Address
+ Translation (NAT) Behavioral Requirements for Unicast
+ UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787,
+ January 2007, <http://www.rfc-editor.org/info/rfc4787>.
+
+ [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
+ Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
+ <http://www.rfc-editor.org/info/rfc4821>.
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 18]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+ Address Autoconfiguration", RFC 4862,
+ DOI 10.17487/RFC4862, September 2007,
+ <http://www.rfc-editor.org/info/rfc4862>.
+
+ [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
+ RFC 4953, DOI 10.17487/RFC4953, July 2007,
+ <http://www.rfc-editor.org/info/rfc4953>.
+
+ [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
+ Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
+ RFC 5382, DOI 10.17487/RFC5382, October 2008,
+ <http://www.rfc-editor.org/info/rfc5382>.
+
+ [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
+ Behavioral Requirements for ICMP", BCP 148, RFC 5508,
+ DOI 10.17487/RFC5508, April 2009,
+ <http://www.rfc-editor.org/info/rfc5508>.
+
+ [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
+ Robustness to Blind In-Window Attacks", RFC 5961,
+ DOI 10.17487/RFC5961, August 2010,
+ <http://www.rfc-editor.org/info/rfc5961>.
+
+ [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
+ Protocol Port Randomization", BCP 156, RFC 6056,
+ DOI 10.17487/RFC6056, January 2011,
+ <http://www.rfc-editor.org/info/rfc6056>.
+
+ [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+ NAT64: Network Address and Protocol Translation from IPv6
+ Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
+ April 2011, <http://www.rfc-editor.org/info/rfc6146>.
+
+ [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
+ Beijnum, "DNS64: DNS Extensions for Network Address
+ Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
+ DOI 10.17487/RFC6147, April 2011,
+ <http://www.rfc-editor.org/info/rfc6147>.
+
+ [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
+ China Education and Research Network (CERNET) IVI
+ Translation Design and Deployment for the IPv4/IPv6
+ Coexistence and Transition", RFC 6219,
+ DOI 10.17487/RFC6219, May 2011,
+ <http://www.rfc-editor.org/info/rfc6219>.
+
+
+
+
+
+Li, et al. Standards Track [Page 19]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
+ P. Roberts, "Issues with IP Address Sharing", RFC 6269,
+ DOI 10.17487/RFC6269, June 2011,
+ <http://www.rfc-editor.org/info/rfc6269>.
+
+ [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using
+ IPv6 Automatic Tunnels: Problem Statement and Proposed
+ Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011,
+ <http://www.rfc-editor.org/info/rfc6324>.
+
+ [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
+ Combination of Stateful and Stateless Translation",
+ RFC 6877, DOI 10.17487/RFC6877, April 2013,
+ <http://www.rfc-editor.org/info/rfc6877>.
+
+ [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
+ W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
+ Configuration of Softwire Address and Port-Mapped
+ Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015,
+ <http://www.rfc-editor.org/info/rfc7598>.
+
+ [Solutions-4v6]
+ Boucadair, M., Ed., Matsushima, S., Lee, Y., Bonness, O.,
+ Borges, I., and G. Chen, "Motivations for Carrier-side
+ Stateless IPv4 over IPv6 Migration Solutions", Work in
+ Progress, draft-ietf-softwire-stateless-4v6-motivation-05,
+ November 2012.
+
+ [Stateless-4Via6]
+ Dec, W., Asati, R., Bao, C., Deng, H., and M. Boucadair,
+ "Stateless 4Via6 Address Sharing", Work in Progress,
+ draft-dec-stateless-4v6-04, October 2011.
+
+ [TR069] Broadband Forum TR-069, "CPE WAN Management Protocol",
+ Amendment 5, CWMP Version: 1.4, November 2013,
+ <https://www.broadband-forum.org>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 20]
+\f
+RFC 7599 MAP-T July 2015
+
+
+Appendix A. Examples of MAP-T Translation
+
+ Example 1 - Basic Mapping Rule:
+
+ Given the following MAP domain information and IPv6 end-user prefix
+ assigned to a MAP CE:
+
+ End-user IPv6 prefix: 2001:db8:0012:3400::/56
+ Basic Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 prefix),
+ 192.0.2.0/24 (Rule IPv4 prefix),
+ 16 (Rule EA-bit length)}
+ PSID length: (16 - (32 - 24) = 8 (sharing ratio of 256)
+ PSID offset: 6 (default)
+
+ A MAP node (CE or BR) can, via the BMR or equivalent FMR, determine
+ the IPv4 address and port set as shown below:
+
+ EA bits offset: 40
+ IPv4 suffix bits (p): Length of IPv4 address (32) -
+ IPv4 prefix length (24) = 8
+ IPv4 address: 192.0.2.18 (0xc0000212)
+ PSID start: 40 + p = 40 + 8 = 48
+ PSID length (q): o - p = (End-user prefix len -
+ Rule IPv6 prefix len) - p
+ = (56 - 40) - 8 = 8
+ PSID: 0x34
+
+ Available ports (63 ranges): 1232-1235, 2256-2259, ...... ,
+ 63696-63699, 64720-64723
+
+ The BMR information allows a MAP CE to determine (complete) its
+ IPv6 address within the indicated End-user IPv6 prefix.
+
+ IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 21]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ Example 2 - BR:
+
+ Another example is a MAP-T BR configured with the following FMR
+ when receiving a packet with the following characteristics:
+
+ IPv4 source address: 10.2.3.4 (0x0a020304)
+ TCP source port: 80
+ IPv4 destination address: 192.0.2.18 (0xc0000212)
+ TCP destination port: 1232
+
+ Forwarding Mapping Rule: {2001:db8::/40 (Rule IPv6 prefix),
+ 192.0.2.0/24 (Rule IPv4 prefix),
+ 16 (Rule EA-bit length)}
+
+ MAP-T BR Prefix (DMR): 2001:db8:ffff::/64
+
+ The above information allows the BR to derive the mapped destination
+ IPv6 address for the corresponding MAP-T CE, and also the source
+ IPv6 address for the mapped IPv4 source address, as follows:
+
+ IPv4 suffix bits (p): 32 - 24 = 8 (18 (0x12))
+ PSID length: 8
+ PSID: 0 x34 (1232)
+
+ The resulting IPv6 packet will have the following header fields:
+
+ IPv6 source address: 2001:db8:ffff:0:000a:0203:0400::
+ IPv6 destination address: 2001:db8:0012:3400:0000:c000:0212:0034
+ TCP source port: 80
+ TCP destination port: 1232
+
+
+ Example 3 - FMR:
+
+ An IPv4 host behind a MAP-T CE (configured as per the previous
+ examples) corresponding with IPv4 host 10.2.3.4 will have its
+ packets converted into IPv6 using the DMR configured on the MAP-T
+ CE as follows:
+
+ Default Mapping Rule: {2001:db8:ffff::/64 (Rule IPv6 prefix),
+ 0.0.0.0/0 (Rule IPv4 prefix)}
+
+ IPv4 source address: 192.0.2.18
+ IPv4 destination address: 10.2.3.4
+ IPv4 source port: 1232
+ IPv4 destination port: 80
+ MAP-T CE IPv6 source address: 2001:db8:0012:3400:0000:c000:0212:0034
+ IPv6 destination address: 2001:db8:ffff:0:000a:0203:0400::
+
+
+
+Li, et al. Standards Track [Page 22]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ Example 4 - Rule with no embedded address bits and no address
+ sharing:
+
+ End-user IPv6 prefix: 2001:db8:0012:3400::/56
+ Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
+ 192.0.2.1/32 (Rule IPv4 prefix),
+ 0 (Rule EA-bit length)}
+ PSID length: 0 (sharing ratio is 1)
+ PSID offset: n/a
+
+ A MAP node can, via the BMR or equivalent FMR, determine the
+ IPv4 address and port set as shown below:
+
+ EA bits offset: 0
+ IPv4 suffix bits (p): Length of IPv4 address -
+ IPv4 prefix length = 32 - 32 = 0
+ IPv4 address: 192.0.2.18 (0xc0000212)
+ PSID start: 0
+ PSID length: 0
+ PSID: null
+
+ The BMR information allows a MAP CE to also determine (complete) its
+ full IPv6 address by combining the IPv6 prefix with the MAP interface
+ identifier (that embeds the IPv4 address).
+
+ IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0201:0000
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 23]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ Example 5 - Rule with no embedded address bits and address sharing
+ (sharing ratio of 256):
+
+ End-user IPv6 prefix: 2001:db8:0012:3400::/56
+ Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
+ 192.0.2.18/32 (Rule IPv4 prefix),
+ 0 (Rule EA-bit length)}
+ PSID length: (16 - (32 - 24)) = 8 (sharing ratio of 256;
+ provisioned with DHCPv6)
+ PSID offset: 6 (default)
+ PSID: 0x20 (provisioned with DHCPv6)
+
+ A MAP node can, via the BMR, determine the IPv4 address and port set
+ as shown below:
+
+ EA bits offset: 0
+ IPv4 suffix bits (p): Length of IPv4 address -
+ IPv4 prefix length = 32 - 32 = 0
+ IPv4 address 192.0.2.18 (0xc0000212)
+ PSID start: 0
+ PSID length: 8
+ PSID: 0x34
+
+ Available ports (63 ranges): 1232-1235, 2256-2259, ...... ,
+ 63696-63699, 64720-64723
+
+ The BMR information allows a MAP CE to also determine (complete) its
+ full IPv6 address by combining the IPv6 prefix with the MAP interface
+ identifier (that embeds the IPv4 address and PSID).
+
+ IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034
+
+ Note that the IPv4 address and PSID are not derived from the IPv6
+ prefix assigned to the CE but are provisioned separately, using, for
+ example, MAP options in DHCPv6.
+
+Appendix B. Port-Mapping Algorithm
+
+ The driving principles and the mathematical expression of the mapping
+ algorithm used by MAP can be found in Appendix B of [RFC7597].
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 24]
+\f
+RFC 7599 MAP-T July 2015
+
+
+Acknowledgements
+
+ This document is based on the ideas of many, particularly Remi
+ Despres, who has tirelessly worked on generalized mechanisms for
+ stateless address mapping.
+
+ The authors would also like to thank Mohamed Boucadair, Guillaume
+ Gottard, Dan Wing, Jan Zorz, Nejc Skoberne, Tina Tsou, Gang Chen,
+ Maoke Chen, Xiaohong Deng, Jouni Korhonen, Tomek Mrugalski, Jacni
+ Qin, Chunfa Sun, Qiong Sun, Leaf Yeh, Andrew Yourtchenko, Roberta
+ Maglione, and Hongyu Chen for their review and comments.
+
+Contributors
+
+ The following individuals authored major contributions to this
+ document and made the document possible:
+
+ Chongfeng Xie
+ China Telecom
+ Room 708, No. 118, Xizhimennei Street
+ Beijing 100035
+ China
+ Phone: +86-10-58552116
+ Email: xiechf@ctbri.com.cn
+
+ Qiong Sun
+ China Telecom
+ Room 708, No. 118, Xizhimennei Street
+ Beijing 100035
+ China
+ Phone: +86-10-58552936
+ Email: sunqiong@ctbri.com.cn
+
+ Rajiv Asati
+ Cisco Systems
+ 7025-6 Kit Creek Road
+ Research Triangle Park, NC 27709
+ United States
+ Email: rajiva@cisco.com
+
+ Gang Chen
+ China Mobile
+ 29, Jinrong Avenue
+ Xicheng District, Beijing 100033
+ China
+ Email: phdgang@gmail.com, chengang@chinamobile.com
+
+
+
+
+
+Li, et al. Standards Track [Page 25]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ Wentao Shang
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing 100084
+ China
+ Email: wentaoshang@gmail.com
+
+ Guoliang Han
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing 100084
+ China
+ Email: bupthgl@gmail.com
+
+ Yu Zhai
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing 100084
+ China
+ Email: jacky.zhai@gmail.com
+
+Authors' Addresses
+
+ Xing Li
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing 100084
+ China
+
+ Email: xing@cernet.edu.cn
+
+
+ Congxiao Bao
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing 100084
+ China
+
+ Email: congxiao@cernet.edu.cn
+
+
+ Wojciech Dec (editor)
+ Cisco Systems
+ Haarlerbergpark Haarlerbergweg 13-19
+ Amsterdam, NOORD-HOLLAND 1101 CH
+ The Netherlands
+
+ Email: wdec@cisco.com
+
+
+
+Li, et al. Standards Track [Page 26]
+\f
+RFC 7599 MAP-T July 2015
+
+
+ Ole Troan
+ Cisco Systems
+ Philip Pedersens vei 1
+ Lysaker 1366
+ Norway
+
+ Email: ot@cisco.com
+
+
+ Satoru Matsushima
+ SoftBank Telecom
+ 1-9-1 Higashi-Shinbashi, Munato-ku
+ Tokyo
+ Japan
+
+ Email: satoru.matsushima@g.softbank.co.jp
+
+
+ Tetsuya Murakami
+ IP Infusion
+ 1188 East Arques Avenue
+ Sunnyvale, CA 94085
+ United States
+
+ Email: tetsuya@ipinfusion.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 27]
+\f
projects / freeradius.git / commitdiff