RFC 5998
An Extension for EAP-Only Authentication in IKEv2
RFC 5998: An Extension for EAP-Only Authentication in IKEv2 🎀
Okay bestie, this one is an IETF Standards Track doc from September 2010 (ISSN 2070-1721) 💅. The authors are P. Eronen (Independent), H. Tschofenig (Nokia Siemens Networks), and Y. Sheffer (Independent). It updates RFC 5996 and doesn't obsolete anything 🦋. Its whole job is making IKEv2 work with EAP methods that give you mutual authentication, without needing the public key signatures that RFC 5996 currently requires.
Abstract 💖
Okay so, IKEv2 says EAP authentication must be used together with responder authentication based on public key signatures 🙈. That's necessary for old EAP methods that only do unilateral authentication, like one-time passwords or token cards (e.g., ones you carry around on a keyring 🔑).
This document explains how EAP methods that do mutual authentication and key agreement can give you extensible responder authentication for IKEv2, based on something other than public key signatures. It's giving flexibility 🌈.
Status of This Memo ⭐
This is an Internet Standards Track document ✨.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more about Internet Standards, check out Section 2 of RFC 5741 📚.
Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc5998 🔗.
Copyright Notice 🌸
Copyright (c) 2010 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) as they stand on the date of publication. Please actually read these, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no 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 people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So, unless you get an adequate license from whoever controls that copyright, this document may not be modified outside the IETF Standards Process, and derivative works may not be created outside it either. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍.
1. Introduction ✨
Okay so the Extensible Authentication Protocol (EAP), defined in [RFC3748], is an authentication framework that supports multiple authentication mechanisms 🧚. It's already running on end hosts and routers that connect through switched circuits or dial-up lines using PPP [RFC1661], on IEEE 802 wired switches [IEEE8021X], and on IEEE 802.11 wireless access points [IEEE80211i] 📡.
The big advantage of the EAP architecture is how flexible it is 💅. EAP is used to pick a specific authentication mechanism, usually after the authenticator asks for more info so it can figure out which method to use. Instead of making the authenticator (like a wireless LAN access point) get updated for every new method, EAP lets you use a backend authentication server that can implement some or all of the methods. Iconic behaviour 👑.
IKEv2 ([RFC4306] and [RFC5996]) is a component of IPsec. It's used for mutual authentication and for establishing and maintaining Security Associations (SAs) for IPsec ESP and Authentication Header (AH) 🔐. Besides authentication with public key signatures and shared secrets, IKEv2 also supports EAP authentication 💜.
IKEv2 got EAP authentication because people realised public key signatures and shared secrets just aren't flexible enough for a lot of deployment scenarios 🙈. With EAP, IKEv2 can reuse existing authentication infrastructure and credential databases. EAP also lets users choose a method that fits the credentials they already have. And it makes it way easier to split the IKEv2 responder (the VPN gateway) from the EAP authentication endpoint (the backend Authentication, Authorization, and Accounting (AAA) server) 🧩.
Some older EAP methods only do unilateral authentication (that's EAP peer to EAP server) 😤. These get paired with IKEv2 public-key-based authentication of the responder to the initiator. The expectation is that this approach is especially useful for "road warrior" VPN gateways, which might use one-time passwords or token cards to authenticate the clients 🧳.
Most newer EAP methods, like the ones typically used with IEEE 802.11i wireless LANs, give you mutual authentication and key agreement 🔥. Right now though, IKEv2 says these EAP methods must also be used together with responder authentication based on public key signatures. Kinda extra, honestly 💀.
For public key signature authentication of the gateway to actually be effective, a deployment of Public Key Infrastructure (PKI) is required. That PKI has to include management of trust anchors on all supplicants 🔑. In a lot of environments that's just not realistic, and the security of the gateway's public key ends up being the same as the security of a self-signed certificate 😭. Mutually authenticating EAP methods on their own can be a sufficient level of security in many circumstances. In fact, some deployments of IEEE 802.11i use EAP without any PKI at all for authenticating the Wireless Local Area Network (WLAN) access points 🦋.
So this document specifies how EAP methods that offer mutual authentication and key agreement can be used to provide responder authentication in IKEv2, completely based on EAP 🎀.
1.1. Terminology 📖
All notation in this protocol extension is taken from [RFC4306].
Numbered messages refer to the IKEv2 message sequence when using EAP. So here's the breakdown:
- Message 1 is the request message of IKE_SA_INIT.
- Message 2 is the response message of IKE_SA_INIT.
- Message 3 is the first request of IKE_AUTH.
- Message 4 is the first response of IKE_AUTH.
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] 🤓.
2. Scenarios 🗺️
Okay so in this section we walk through two scenarios for extensible authentication within IKEv2. They're meant as illustrative examples, not as a rulebook for how things should be done 💖.
Figure 1 shows a setup where the EAP and IKEv2 endpoints are co-located. In that case, authenticating the IKEv2 responder with both EAP and public key signatures is redundant 🙈. Still, offering EAP-based authentication has a real perk: multiple different authentication and key exchange protocols are available through EAP, each with different security properties (like strong password-based protocols, protocols that give user identity confidentiality, and many more) ✨.
+------+-----+ +------------+
O | IKEv2 | | IKEv2 |
/|\ | Initiator |<---////////////////////--->| Responder |
/ \ +------------+ IKEv2 +------------+
User | EAP Peer | Exchange | EAP Server |
+------------+ +------------+
Figure 1: EAP and IKEv2 Endpoints Are Co-LocatedFigure 2 is a typical corporate network access scenario 🏢. The initiator (client) talks to the responder (VPN gateway) inside the corporate network. The EAP exchange within IKE runs between the client and the home AAA server. When the EAP authentication protocol run succeeds, session keys get established and sent from the AAA server to the VPN gateway. The gateway then uses them to authenticate the IKEv2 SA with AUTH payloads 🔐.
The protocol between the VPN gateway and the AAA server could be, for instance, Diameter [RFC4072] or RADIUS [RFC3579]. Check out Section 6 for related security considerations ⚠️.
+-------------------------------+
| Corporate network |
| |
+-----------+ +--------+ |
| IKEv2 | AAA | Home | |
IKEv2 +////----->+ Responder +<---------->+ AAA | |
Exchange / | (VPN GW) | (RADIUS/ | Server | |
/ +-----------+ Diameter) +--------+ |
/ | carrying EAP |
| | |
| +-------------------------------+
v
+------+-----+
o | IKEv2 |
/|\ | Initiator |
/ \ | VPN client |
User +------------+
Figure 2: Corporate Network AccessStay tuned bestie, part 2 is coming 🦋💜
3. Solution 💖
okay so IKEv2 has this rule: when the EAP method sets up a shared secret key, both the initiator and the responder use that key to make an AUTH payload 🔐. That's how the IKEv2 SA set up by messages 1 and 2 gets authenticated, and it's giving main character energy.
When you pair this with public key responder authentication, the responder gets authenticated using two different methods ✨: the public key signature AUTH payload in message 4, and then the EAP-based AUTH payload later on. Double check, lowkey iconic.
If the initiator doesn't want public-key-based responder authentication, it includes an EAP_ONLY_AUTHENTICATION notification payload (16417) in message 3 🎀. The Protocol ID and Security Parameter Index (SPI) size fields are set to zero, and there's no extra data attached to this notification.
If the responder supports this notification and decides to use it, it leaves out the public-key-based AUTH payload and CERT payloads from message 4 🦋.
If the responder doesn't support EAP_ONLY_AUTHENTICATION, or just doesn't want to use it, it ignores the notification payload and includes the AUTH payload in message 4. In this case, the initiator MUST verify that payload and any associated certificates, as per [RFC4306] 🧐.
When the initiator receives message 4, it MUST verify that the proposed EAP method is allowed by this specification, and it MUST abort the protocol immediately otherwise 🚫.
Both the initiator and responder MUST verify that the EAP method actually used provided mutual authentication and established a shared secret key 🤝. The AUTH payloads sent after EAP Success MUST use the EAP-generated key, and they MUST NOT use SK_pi or SK_pr (see Section 2.15 of [RFC5996]). Not me being extra about key separation, but yes 💅.
An IKEv2 message exchange with this modification looks like this 👀:
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni,
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)] -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ],
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)]
HDR, SK { IDi, [IDr], SAi2, TSi, TSr,
N(EAP_ONLY_AUTHENTICATION),
[CP(CFG_REQUEST)] } -->
<-- HDR, SK { IDr, EAP(Request) }
HDR, SK { EAP(Response) } -->
<-- HDR, SK { EAP(Request) }
HDR, SK { EAP(Response) } -->
<-- HDR, SK { EAP(Success) }
HDR, SK { AUTH } -->
<-- HDR, SK { AUTH, SAr2, TSi, TSr,
[CP(CFG_REPLY] }Quick note 📝: all notation in the above protocol sequence, and everywhere else in this spec, is as defined in [RFC4306]. Check out Sec. 1.2 of [RFC4306] for the payload types, especially 🫶.
The NAT detection and Configuration payloads are only there for informative purposes. They don't change how EAP authentication works 💁♀️.
An IKE SA that was set up with this extension can be resumed using the mechanism described in [RFC5723] 🔁. BUT, and this is a big one, session resumption doesn't change the authentication method. So during the IKE_AUTH exchange of the resumed session, the initiator MUST NOT send this extension 🙅♀️.
4. Safe EAP Methods 🛡️
okay bestie, EAP methods used with this extension MUST have these three properties:
- The method provides mutual authentication of the peers.
- The method is key-generating.
- The method is resistant to dictionary attacks.
The authors believe the methods below are secure when used with this extension. The list isn't complete, and there are probably other safe methods that aren't listed here 🌸.
+-------------------------------+-------------------+---------------+
| Method Name | Allows Channel | Reference |
| | Binding? | |
+-------------------------------+-------------------+---------------+
| EAP-SIM | No | [RFC4186] |
| EAP-AKA | Yes | [RFC4187] |
| EAP-AKA' | Yes | [RFC5448] |
| EAP-GPSK | Yes | [RFC5433] |
| EAP-pwd | No | [RFC5931] |
| EAP-EKE | Yes | [EMU-EAP-EKE] |
| EAP-PAX | Yes | [RFC4746] |
| EAP-SAKE | No | [RFC4763] |
| EAP-SRP | No | [EAP-SRP] |
| EAP-POTP (mutual | Yes | [RFC4793] |
| authentication variant) | | |
| EAP-TLS | No | [RFC5216] |
| EAP-FAST | No | [RFC4851] |
| EAP-TTLS | No | [RFC5281] |
+-------------------------------+-------------------+---------------+The "Allows channel binding?" column marks protocols where protected identity info can be sent between the EAP endpoints 🎭. This third property is optional, and it protects against certain kinds of attacks (see Section 6.2 for the explanation). So in some situations, methods that allow channel binding are the ones to pick 🏆. Here's the tea: even when those capabilities exist, they aren't fully specified in an interoperable way yet. Specifically, no RFC says which identities should go under the channel binding protection, or what policy should be used to match up identities at the different layers 😭.
5. IANA Considerations 📋
This document defines a new IKEv2 Notification Payload type, EAP_ONLY_AUTHENTICATION, described in Section 3 ✨. It got the type number 16417 from the "Status Types" range 🔢.
6. Security Considerations 🚨
Security considerations that apply to all EAP methods are covered in [RFC3748] 🔒. The EAP Key Management Framework [RFC5247] deals with the issues that show up when EAP is part of a bigger system. Read it, it matters 💀.
6.1. Authentication of IKEv2 SA 🔑
Important tea: the IKEv2 SA isn't authenticated just by running an EAP conversation 🙈. The crucial step is the AUTH payload based on the EAP-generated key. So EAP methods that don't provide mutual authentication or establish a shared secret key MUST NOT be used with the modifications in this document 🚫.
6.2. Authentication with Separated IKEv2 Responder / EAP Server 🏰
As described in Section 2, the EAP conversation can end either at the IKEv2 responder or at a backend AAA server 🧚.
If the EAP method terminates at the IKEv2 responder, then no key transport through the AAA infrastructure is needed. The pre-shared secret and public-key-based authentication that IKEv2 offers get replaced by a wider range of authentication and key exchange methods 🌈.
Typically though, EAP gets used with a backend AAA server. Check [RFC5247] for a more complete discussion of the security issues involved. Here we just give a short summary 📖.
When a backend server is used, there are actually two authentication exchanges 👯: the EAP method between the client and the AAA server, and another authentication between the AAA server and the IKEv2 gateway. The AAA server authenticates the client using the selected EAP method, and they establish a session key. Then the AAA server sends this key to the IKEv2 gateway over a connection authenticated using, e.g., IPsec or Transport Layer Security (TLS).
Some EAP methods don't have any concept of a pass-through authenticator identity (like a Network Access Server (NAS) or IKEv2 gateway), so these two authentications stay pretty independent of each other 🫠. That means after the client verifies the AUTH payload sent by the IKEv2 gateway, it knows it's talking to SOME gateway trusted by the home AAA server, but not which one 👀. It's kind of similar if a single cryptographic hardware accelerator, holding a single private key, is shared between multiple IKEv2 gateways (maybe in some kind of cluster setup). Especially, if one of the gateways gets compromised, it can impersonate any of the other gateways toward the user, until the compromise is discovered and access rights are revoked 😱.
In some environments, it's not desirable to trust the IKEv2 gateways this much (also known as the "Lying NAS Problem") 🙃. EAP methods that provide "connection binding" or "channel binding" carry some identity or identities of the gateway (or WLAN access point / NAS) inside the EAP method. Then the AAA server can check that it's really sending the key to the gateway the client expected 🎯. A potential solution is described in [EAP-SERVICE], and see also [EMU-AAAPAY].
In some deployments, AAA proxies might sit between the IKEv2 gateway and the backend AAA server. These AAA proxies MUST be trusted for secure operation, so they SHOULD be avoided when possible 🙏. See Section 2.3.4 of [RFC4072] and Section 4.3.7 of [RFC3579] for more.
6.3. Protection of EAP Payloads 🧱
Even though the EAP payloads are encrypted and integrity protected with SK_e/SK_a, that doesn't protect against active attackers 😬. Until the AUTH payload has been received and verified, a man-in-the-middle can change the KEi/KEr payloads and eavesdrop on or modify the EAP payloads. Yikes.
In IEEE 802.11i wireless LANs, the EAP payloads are neither encrypted nor integrity protected (by the link layer), so EAP methods are usually designed with that in mind 📶.
Especially, EAP methods that are vulnerable to dictionary attacks when used in WLANs are still vulnerable to active attackers when run inside IKEv2 💔.
The rules in Section 4 are designed to avoid this potential vulnerability 🛡️✨.
6.4. Identities and Authenticated Identities 🪪
When using this protocol, each peer sends two identity values:
- An identity contained in the IKE ID payload.
- An identity transferred within the specific EAP method's messages.
(IKEv2 omits the EAP Identity request/response pair, see Section 3.16 of [RFC5996].) The first identity value can be used by the recipient to route AAA messages and/or to select authentication and EAP types 🗺️. But only the second identity is directly authenticated by the EAP method. The reader is referred to Section 2.16 of [RFC5996] about basing IPsec policy decisions on the authenticated identity 📚. In the context of the extension described here, this IPsec policy guidance applies to both the gateway's authentication of the client and the client's authentication of the gateway 💜.
6.5. User Identity Confidentiality ✨
okay so IKEv2 keeps the initiator's identity private from passive eavesdroppers 👀 but NOT from active attackers 💀. the initiator says who it is in message 3, before the responder has been authenticated. using EAP doesn't fix this, because the ID payload in message 3 is used instead of the EAP Identity Request/Response exchange. it's kinda sad tbh 😭, since if EAP is paired with public key authentication of the responder, you could get active user identity confidentiality for the initiator. so close!! 🥺
IKEv2 protects the responder's identity even against active attacks 🛡️. that's the main character energy this property has, but it can't be provided when using EAP. if public key responder authentication is used in addition to EAP, the responder reveals its identity before authenticating the initiator. if only EAP is used (like this document proposes), it depends on the EAP method, because in some EAP methods the server reveals its identity first 🫠.
so, if you need active user identity confidentiality for the responder, you have to use EAP methods that offer it (see [RFC3748], Section 7.3) 🔐💅
7. Acknowledgments 🫶
this document borrows some text from [RFC3748], [RFC4306], and [RFC4072] 📝. big thanks to Hugo Krawczyk for the interesting discussions on this topic, and to Dan Harkins and David Harrington for their comments 🌸.
8. References 📚
8.1. Normative References 💜
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
- [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
- [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
8.2. Informative References 🦋
- [EAP-SERVICE] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", Work in Progress, October 2005.
- [EAP-SRP] Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 Authentication Protocol", Work in Progress, July 2001.
- [EMU-AAAPAY] Clancy, C., Lior, A., Zorn, G., and K. Hoeper, "EAP Method Support for Transporting AAA Payloads", Work in Progress, May 2010.
- [EMU-EAP-EKE] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An EAP Authentication Method Based on the EKE Protocol", Work in Progress, August 2010.
- [IEEE80211i] Institute of Electrical and Electronics Engineers, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment 6: Medium Access Control (MAC) Security Enhancements", IEEE Standard 802.11i-2004, July 2004.
- [IEEE8021X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2001, 2001.
- [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
- [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.
- [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006.
- [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
- [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication Protocol (EAP) Password Authenticated Exchange", RFC 4746, November 2006.
- [RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)", RFC 4763, November 2006.
- [RFC4793] Nystroem, M., "The EAP Protected One-Time Password Protocol (EAP-POTP)", RFC 4793, February 2007.
- [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007.
- [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
- [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
- [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
- [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, February 2009.
- [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", RFC 5448, May 2009.
- [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication Protocol (EAP) Authentication Using Only A Password", RFC 5931, August 2010.
Appendix A. Alternative Approaches 🧚
in this section we list the alternatives that got considered while working on this document 💭. we concluded that the solution presented in Section 3 fits better into IKEv2 🎀.
A.1. Ignore AUTH Payload at the Initiator 🙈
with this approach, the initiator just ignores the AUTH payload in message 4 (but it obviously has to check the second AUTH payload later!!) 😤. the main advantage is that no protocol modifications are needed and no signature verification is needed 🙌. the big disadvantage is that the EAP method to be used can't be selected to take this behavior into account 💀.
the initiator could signal to the responder (using a notification payload) that it did not verify the first AUTH payload 📣.
A.2. Unauthenticated Public Keys in AUTH Payload (Message 4) 🔑
another solution approach suggests using unauthenticated public keys in the public key signature AUTH payload (for message 4) 🤔.
that is, the initiator verifies the signature in the AUTH payload, but does not verify that the public key actually belongs to the intended party (using certificates), since it doesn't have a PKI that would allow this 🫤. this could be used with X.509 certificates (the initiator ignores all other fields of the certificate except the public key), or "Raw RSA Key" CERT payloads.
this approach has the advantage that initiators who want to do certificate-based responder authentication (in addition to EAP) may do so, without requiring the responder to handle these cases separately ✨. a disadvantage here, again, is that the EAP method selection can't take into account the incomplete validation of the responder's certificate 😬.
if using RSA, the overhead of signature verification is quite small, compared to the g^xy calculation required by the Diffie-Hellman exchange 🧮.
A.3. Using EAP Derived Session Keys for IKEv2 🗝️
it has been proposed that when using an EAP method that provides mutual authentication and key agreement, the IKEv2 Diffie-Hellman exchange could also be omitted 🤯. this would mean the session keys for IPsec SAs established later would rely only on the EAP-provided keys.
the only benefit of this approach seems to be saving some computation time (g^xy calculation) 🥱. this approach requires designing a completely new protocol (which would no longer resemble IKEv2) 🙅♀️, so we don't believe it should be considered. we include it anyway, for completeness 📎.
Authors' Addresses 💌
Pasi Eronen
Independent
EMail: pe@iki.fi
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Yaron Sheffer
Independent
EMail: yaronf.ietf@gmail.com📦 where this page comes from
- ietf: rfc5998 2010-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms