RFC 7055
A GSS-API Mechanism for the Extensible Authentication Protocol
Pages: 35
Proposed Standard
Proposed Standard
Part 2 of 2 – Pages 18 to 35
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
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 |
+-------------+-----------------------+
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.
+-------------+-----------------------------------------------+
| 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
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" |
+-------------------------------------------+
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
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.
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
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
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.
+--------------------------------+-------+--------------------------+ | 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].
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 |
+-------+------------------------------------------------+
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.
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.
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.
[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.
[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.
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