--- 1/draft-ietf-hokey-rfc5296bis-01.txt 2011-03-14 08:14:15.000000000 +0100 +++ 2/draft-ietf-hokey-rfc5296bis-02.txt 2011-03-14 08:14:15.000000000 +0100 @@ -1,23 +1,23 @@ Network Working Group Q. Wu, Ed. Internet-Draft Huawei Obsoletes: 5296 (if approved) Z. Cao Intended status: Standards Track China Mobile -Expires: April 23, 2011 Y. Shi +Expires: September 15, 2011 Y. Shi H3C B. He CATR - October 20, 2010 + March 14, 2011 EAP Extensions for EAP Re-authentication Protocol (ERP) - draft-ietf-hokey-rfc5296bis-01 + draft-ietf-hokey-rfc5296bis-02 Abstract The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any @@ -32,25 +32,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 23, 2011. + This Internet-Draft will expire on September 15, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 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 @@ -79,43 +79,45 @@ 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 14 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 14 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 15 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 15 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20 - 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 22 + 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 23 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 23 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 24 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 25 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 26 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 26 - 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 26 + 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 27 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 28 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 - 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32 + 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 33 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33 - 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 34 + 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 39 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 41 - A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 41 - A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 41 + 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 10.1. draft-ietf-hokey-rfc5296bis-02 . . . . . . . . . . . . . . 39 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 40 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 40 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42 + A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 42 + A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 42 Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 42 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction The Extensible Authentication Protocol (EAP) is a an authentication framework that supports multiple authentication methods. The primary purpose is network access authentication, and a key-generating method is used when the lower layer wants to enforce access control. The EAP keying hierarchy defines two keys to be derived by all key- generating EAP methods: the Master Session Key (MSK) and the Extended MSK (EMSK). In the most common deployment scenario, an EAP peer and @@ -154,22 +156,22 @@ efficient re-authentication using EAP. The protocol that uses these extensions is itself referred to as the EAP Re-authentication Protocol (ERP). It supports EAP method-independent re-authentication for a peer that has valid, unexpired key material from a previously performed EAP authentication. The protocol and the key hierarchy required for EAP re-authentication are described in this document. Note that to support ERP, lower-layer specifications may need to be revised to allow carrying EAP messages that have a code value higher than 4 and to accommodate the peer-initiated nature of ERP. - Specifically, the IEEE802.1x specification must be revised and RFC - 4306 must be updated to carry ERP messages. + Specifically, the IEEE802.1x specification [IEEE_802.1X] must be + revised and RFC 5996 [RFC5996] must be updated to carry ERP messages. 2. Terminology 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]. This document uses the basic EAP terminology [RFC3748] and EMSK keying hierarchy terminology [RFC5295]. In addition, this document uses the following terms: @@ -259,22 +261,22 @@ <----AAA(MSK, EAP-Success)------ <---EAP-Success--------- Figure 1: EAP Authentication Peer ER Authenticator ER Server ==== ============= ====== - [<-- EAP-Initiate/ ----- - Re-auth-Start] + <-- EAP-Initiate/ ----- + Re-auth-Start [<-- EAP-Request/ ------ Identity] ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> Re-auth/ Re-auth/ [Bootstrap] [Bootstrap]) <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- Re-auth/ Re-auth/ [Bootstrap] [Bootstrap]) @@ -385,22 +387,22 @@ with the home ER server to obtain the domain name. The defined ER extensions allow executing the ERP with an ER server in the home domain. The home ER server may be co- located with a home AAA server. The ERP with the Home ER Server is the similar as ERP exchange described in Figure 2. Peer ER Authenticator Home ER Server ==== ============= ====== - [<-- EAP-Initiate/ ----- - Re-auth-Start] + <-- EAP-Initiate/ ----- + Re-auth-Start [<-- EAP-Request/ ------ Identity] ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> Re-auth/ Re-auth/ [Bootstrap] [Bootstrap]) <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- Re-auth/ Re-auth/ [Bootstrap] [Bootstrap]) @@ -447,22 +449,22 @@ <--- AAA(MSK, ----- EAP-Success) <---EAP-Success----- Figure 4: Local ERP Exchange, Initial EAP Exchange Peer ER Authenticator Local ER Server ==== ================ =============== - [<-- EAP-Initiate/ -------- - Re-auth-Start] + <-- EAP-Initiate/ -------- + Re-auth-Start [<-- EAP-Request/ --------- Identity] ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ --------> Re-auth Re-auth) <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- Re-auth Re-auth) Figure 5: Local ERP Exchange @@ -717,84 +719,97 @@ new rRK. Previously delivered rMSKs MAY still be used until the expiry of the lifetime. o A given rMSK MUST NOT be shared by multiple authenticators. 5. Protocol Details 5.1. ERP Bootstrapping We identify two types of bootstrapping for ERP: explicit and implicit - bootstrapping. In implicit bootstrapping, the local AAA client or - agent supporting EAP re-authentication SHOULD include its domain name - and SHOULD request the DSRK from the home AAA server during the - initial EAP exchange, in the AAA message encapsulating the first EAP - Response message sent by the peer. If such EAP exchange is - successful, the home EAP server sends the DSRK for the specified - local AAA client or agent (derived using the EMSK and the domain name - as specified in [RFC5295]), EMSKname, and DSRK lifetime along with - the EAP-Success message. The local AAA client or agent MUST extract - the DSRK, EMSKname, and DSRK lifetime (if present) before forwarding - the EAP-Success message to the peer, as specified in - [I-D.ietf-dime-erp]. Note that the MSK (also present along with the - EAP Success message) is extracted by the EAP authenticator as usual. - The peer learns the domain name through the EAP-Initiate/ - Re-auth-Start message, lower-layer announcements - [I-D.ietf-hokey-ldn-discovery] or via ER Explicit bootstrapping - exchange. When the domain name is available to the peer during or - after the full EAP authentication, it attempts to use ERP when it - associates with a new authenticator. + bootstrapping. In implicit bootstrapping, if the local AAA client or + Agent do not have the keying material(e.g., rMSK or rRK) + corresponding to the peer, the local AAA client or agent supporting + EAP re-authentication SHOULD include its domain name and SHOULD + request the DSRK from the home AAA server during the initial EAP + exchange, in the AAA message encapsulating the first EAP Response + message sent by the peer. If such EAP exchange is successful, the + home EAP server sends the DSRK for the specified local AAA client or + agent (derived using the EMSK and the domain name as specified in + [RFC5295]), EMSKname, and DSRK lifetime along with the EAP-Success + message. The local AAA client or agent MUST extract the DSRK, + EMSKname, and DSRK lifetime (if present) before forwarding the EAP- + Success message to the peer, as specified in [I-D.ietf-dime-erp]. + Note that the MSK (also present along with the EAP Success message) + is extracted by the EAP authenticator as usual. The peer learns the + domain name through the EAP-Initiate/Re-auth-Start message, lower- + layer announcements [I-D.ietf-hokey-ldn-discovery] . When the domain + name is available to the peer during or after the full EAP + authentication, it attempts to use ERP when it associates with a new + authenticator. If the peer does not know the domain name (did not receive the domain name through the EAP-Initiate/Re-auth-Start message or via the lower- layer announcement, due to a missed announcement or lack of support for domain name announcements in a specific lower layer), it SHOULD - initiate Explicit ER bootstrap exchange (ERP exchange with the - bootstrap flag turned on) with the ER server in the same (visited) - domain as the peer to obtain the local domain name. The peer MAY - also initiate bootstrapping to fetch information such as the rRK - lifetime from the AAA server. + initiate Explicit ERP bootstrapping (ERP exchange with the bootstrap + flag turned on) with the ER server to obtain the local domain name. - The following steps describe the ERP explicit bootstrapping process: + The peer MAY also initiate bootstrapping to fetch information such as + the rRK lifetime from the AAA server. + + The following steps describe the ERP Explicit Bootstrapping process: o The peer sends the EAP-Initiate/Re-auth message with the bootstrapping flag turned on. The bootstrap message is always sent to the ER server, and the keyname-NAI attribute in the bootstrap message is constructed as follows: the username portion of the NAI contains the EMSKname, and the realm portion contains the home domain name. o In addition, the message MUST contain a sequence number for replay protection, a cryptosuite, and an integrity checksum. The cryptosuite indicates the authentication algorithm. The integrity checksum indicates that the message originated at the claimed entity, the peer indicated by the Peer-ID, or the rIKname. o The peer MAY additionally set the lifetime flag to request the key lifetimes. o When an ERP-capable authenticator receives the EAP-Initiate/ Re-auth message from a peer, it copies the contents of the - keyName-NAI into the User-Name attribute of RADIUS [RFC2865]. The - rest of the process is similar to that described in [RFC3579]. + keyName-NAI into the User-Name attribute of RADIUS [RFC2865] and + may include its domain name in the AAA message encapsulating the + EAP-Initiate/Re-auth message sent by the peer. The rest of the + process is similar to that described in [RFC3579]. - o Upon receipt of an EAP-Initiate/Re-auth message, the server - verifies whether the message is fresh or is a replay by evaluating - whether the received sequence number is equal to or greater than - the expected sequence number for that rIK. The server then - verifies to ensure that the cryptosuite used by the peer is - acceptable. Next, it verifies the origin authentication of the - message by looking up the rIK. If any of the checks fail, the - server sends an EAP-Finish/Re-auth message with the Result flag - set to '1'. Please refer to Section 5.2.2 for details on failure - handling. This error MUST NOT have any correlation to any EAP- - Success message that may have been received by the EAP + o If a local ER server is present, the local ER server MUST verify + whether it has DSRK corresponding to the peer. If the local ER + server has the key materials corresponding to the peer, it MUST be + able to respond directly in the same way as the home ER server + does described in the following step without forwarding the ERP + message to the home domain, even if this message contains the 'B' + (bootstrapping) flag. Otherwise, the local ER server MUST include + the DSRK request and its domain name in the AAA message + encapsulating the EAP-Initiate/Re-auth message sent by the peer. + + o Upon receipt of an EAP-Initiate/Re-auth message, the home ER + server verifies whether the message is fresh or is a replay by + evaluating whether the received sequence number is equal to or + greater than the expected sequence number for that rIK. The home + ER server then verifies to ensure that the cryptosuite used by the + peer is acceptable. Next, it verifies the origin authentication + of the message by looking up the rIK. If any of the checks fail, + the home ER server sends an EAP-Finish/Re-auth message with the + Result flag set to '1'. Please refer to Section 5.2.2 for details + on failure handling. This error MUST NOT have any correlation to + any EAP-Success message that may have been received by the EAP authenticator and the peer earlier. If the EAP-Initiate/Re-auth message is well-formed and valid, the server prepares the EAP- Finish/Re-auth message. The bootstrap flag MUST be set to indicate that this is a bootstrapping exchange. The message contains the following fields: * A sequence number for replay protection. * The same keyName-NAI as in the EAP-Initiate/Re-auth message. @@ -802,43 +817,44 @@ message, the ER server SHOULD include the rRK lifetime and the rMSK lifetime in the EAP-Finish/Re-auth message. The server may have a local policy for the network to maintain and enforce lifetime unilaterally. In such cases, the server need not respond to the peer's request for the lifetime. * If the bootstrap flag is set, the ER server MUST include the domain name to which the DSRK is being sent along with the EAP- Finish/Re-auth message. - * If the ER server verifies the authorization of a local domain + * If the ER server verifies the authorization of a local ER server, it MAY include the Authorization Indication TLV to indicate to the peer that the server (that received the DSRK and that is advertising the domain included in the domain name TLV) is authorized. * An authentication tag MUST be included to prove that the EAP- Finish/Re-auth message originates at a server that possesses the rIK corresponding to the EMSKname-NAI. - o If the ERP exchange is successful, the ER server SHOULD request - the DSRK from the home EAP server during the initial EAP exchange - as specified in [I-D.ietf-dime-local-keytran], the home EAP server + o If the home ER server gets involved in ERP exchange and the ERP + exchange is successful, the home ER server SHOULD request the DSRK + from the home EAP server during this ERP Explicit Bootstrapping as + specified in [I-D.ietf-dime-local-keytran], the home EAP server MUST include the DSRK for the local ER server (derived using the EMSK and the domain name as specified in [RFC5295]), EMSKname, and DSRK lifetime along with the EAP-Finish/Re-auth message. o In addition, the rMSK is sent along with the EAP-Finish/Re-auth message, in a AAA attribute [I-D.ietf-dime-erp]. - o The ER server MUST extract the DSRK, EMSKname, and DSRK lifetime - (if present) before forwarding the EAP-Success message to the - peer, as specified in [I-D.ietf-dime-erp]. + o The local ER server MUST extract the DSRK, EMSKname, and DSRK + lifetime (if present) before forwarding the EAP-Success message to + the peer, as specified in [I-D.ietf-dime-erp]. o The authenticator receives the rMSK. o When the peer receives an EAP-Finish/Re-auth message with the bootstrap flag set, if a local domain name is present, it MUST use that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- NAI, and initialize the replay counter for the DS-rIK. If not, the peer SHOULD derive the domain-specific keys using the domain name it learned via the lower layer or from the EAP-Initiate/ Re-auth-Start message. If the peer does not know the domain name, @@ -890,20 +906,23 @@ Operational Considerations at the Peer: ERP requires that the peer maintain retransmission timers for reliable transport of EAP re-authentication messages. The reliability considerations of Section 4.3 of RFC 3748 apply with the peer as the retransmitting entity. The EAP Re-auth Protocol has the following steps: + The ERP-capable authenticator sends the EAP-Initiate/Re-auth-Start + message to trigger the ERP exchange. + The peer sends an EAP-Initiate/Re-auth message. At a minimum, the message SHALL include the following fields: a 16-bit sequence number for replay protection keyName-NAI as a TLV attribute to identify the rIK used to integrity protect the message. cryptosuite to indicate the authentication algorithm used to compute the integrity checksum. @@ -1130,25 +1149,25 @@ name is to be used as the realm in an NAI [RFC4282]. The Domain-Name attribute SHOULD be present in an EAP-Initiate/ Re-auth-Start message. In addition, channel binding information MAY be included; see Section 5.5 for discussion. See Figure 12 for parameter specification. 5.3.1.1. Authenticator Operation - The authenticator MAY send the EAP-Initiate/Re-auth-Start message to - indicate support for ERP to the peer and to initiate ERP if the peer - has already performed full EAP authentication and has unexpired key - material. The authenticator SHOULD include the domain name TLV to - allow the peer to learn it without lower-layer support or the ERP + The authenticator SHOULD send the EAP-Initiate/Re-auth-Start message + to indicate support for ERP to the peer and to initiate ERP if the + peer has already performed full EAP authentication and has unexpired + key material. The authenticator SHOULD include the domain name TLV + to allow the peer to learn it without lower-layer support or the ERP bootstrapping exchange. The authenticator MAY include channel binding information so that the peer can send the information to the server in the EAP-Initiate/ Re-auth message so that the server can verify whether the authenticator is claiming the same identity to both parties. The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start message a few times for reliable transport. @@ -1507,21 +1527,21 @@ matter; this specification recommends a value of 100 milliseconds. The lower layer may provide facilities for exchanging information between the peer and the authenticator about support for ERP, for the authenticator to send the domain name information and channel binding information to the peer Note that to support ERP, lower-layer specifications may need to be revised. Specifically, the IEEE802.1x specification must be revised to allow carrying EAP messages of the new codes defined in this - document in order to support ERP. Similarly, RFC 4306 must be + document in order to support ERP. Similarly, RFC 5996 must be updated to include EAP code values higher than 4 in order to use ERP with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may also be updated to support peer-initiated ERP for optimized operation. Other lower layers may need similar revisions. Our analysis indicates that some EAP implementations are not RFC 3748 compliant in that instead of silently dropping EAP packets with code values higher than 4, they may consider it an error. To accommodate such non-compliant EAP implementations, additional guidance has been provided below. Furthermore, it may not be easy to upgrade all the @@ -1751,49 +1771,65 @@ enforcement). The model works as long as entities in the middle of the network do not use keys intended for other parties to steal service from an access network. If that is not achievable, key delivery must be protected in an end-to-end manner. 9. IANA Considerations This document has no IANA actions; all values referenced in this document were previously assigned in RFC 5296 [RFC5296]. -10. References +10. Change Log -10.1. Normative References +10.1. draft-ietf-hokey-rfc5296bis-02 + + The following are the major changes compared to previous version 00: + + o Change using MAY in section 5.3.1.1 to using SHOULD + + o Mandate sending the EAP-Initiate/Re-auth-Start message instead of + optional + + o Update obsolete reference RFC4306 into RFC5996 + + o Allow local server respond to the peer directly without forwarding + the ERP message to the home domain + +11. References + +11.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [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. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008. -10.2. Informative References +11.2. Informative References [I-D.ietf-dime-erp] Bournelle, J., Morand, L., Wu, W., and G. Zorn, "Diameter Support for the EAP Re-authentication Protocol (ERP)", - draft-ietf-dime-erp-04 (work in progress), September 2010. + draft-ietf-dime-erp-05 (work in progress), October 2010. [I-D.ietf-dime-local-keytran] , Q. and G. , "Diameter Attribute-Value Pairs for Cryptographic Key Transport", draft-ietf-dime-local-keytran-07 (work in progress), July 2010. [I-D.ietf-hokey-ldn-discovery] Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in @@ -1840,20 +1876,24 @@ IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- authentication Protocol (ERP)", RFC 5296, August 2008. [RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of EAP-Based Keys for Handover and Re-Authentication", RFC 5749, March 2010. + [RFC5996] Kaufman, C., Hoffman , P., Nir, Y., and P. Eronen, + "Internet Key Exchange Protocol Version 2 (IKEv2)", + RFC 5996, September 2010. + Appendix A. Acknowledgments A.1. RFC 5296 In writing this document, we benefited from discussing the problem space and the protocol itself with a number of folks including Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of