Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4186

Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)

Pages: 92
Informational
Errata
Part 5 of 5 – Pages 78 to 92
First   Prev   None

Top   ToC   RFC4186 - Page 78   prevText

15. References

15.1. Normative References

[GSM-03.20] European Telecommunications Standards Institute, "GSM Technical Specification GSM 03.20 (ETS 300 534): "Digital cellular telecommunication system (Phase 2); Security related network functions"", August 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [GSM-03.03] European Telecommunications Standards Institute, "GSM Technical Specification GSM 03.03 (ETS 300 523): "Digital cellular telecommunication system (Phase 2); Numbering, addressing and identification"", April 1997. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [AES] National Institute of Standards and Technology, "Federal Information Processing Standards (FIPS) Publication 197, "Advanced Encryption Standard (AES)"", November 2001. http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf [CBC] National Institute of Standards and Technology, "NIST Special Publication 800-38A, "Recommendation for Block Cipher Modes of Operation - Methods and Techniques"", December 2001. http://csrc.nist.gov/publications/nistpubs/ 800-38a/sp800-38a.pdf [SHA-1] National Institute of Standards and Technology, U.S. Department of Commerce, "Federal Information Processing Standard (FIPS) Publication 180-1, "Secure Hash Standard"", April 1995.
Top   ToC   RFC4186 - Page 79
   [PRF]              National Institute of Standards and Technology,
                      "Federal Information Processing Standards (FIPS)
                      Publication  186-2 (with change notice); Digital
                      Signature Standard (DSS)", January 2000.
                      Available on-line at:
                      http://csrc.nist.gov/publications/
                      fips/fips186-2/fips186-2-change1.pdf

   [RFC3629]          Yergeau, F., "UTF-8, a transformation format of
                      ISO 10646", STD 63, RFC 3629, November 2003.

   [RFC3748]          Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J.,
                      and H. Levkowetz, "Extensible Authentication
                      Protocol (EAP)", RFC 3748, June 2004.

   [EAP-AKA]          Arkko, J. and H. Haverinen, "Extensible
                      Authentication Protocol Method for 3rd Generation
                      Authentication and Key Agreement (EAP-AKA)", RFC
                      4187, January 2006.

15.2. Informative References

[3GPP-TS-23.003] 3rd Generation Partnership Project, "3GPP Technical Specification 3GPP TS 23.003 V6.8.0: "3rd Generation Parnership Project; Technical Specification Group Core Network; Numbering, addressing and identification (Release 6)"", December 2005. [3GPP-TS-55.205] 3rd Generation Partnership Project, "3GPP Technical Specification 3GPP TS 55.205 V 6.0.0: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Specification of the GSM-MILENAGE Algorithms: An example algorithm set for the GSM Authentication and Key Generation functions A3 and A8 (Release 6)"", December 2002. [PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004. [PEAP-02] Anderson, H., Josefsson, S., Zorn, G., Simon, D., and A. Palekar, "Protected EAP Protocol (PEAP)", Work in Progress, February 2002.
Top   ToC   RFC4186 - Page 80
   [EAP-Keying]       Aboba, B., Simon, D., Arkko, J., Eronen, P., and
                      H.  Levkowetz, "Extensible Authentication Protocol
                      (EAP) Key Management Framework", Work in Progress,
                      October 2005.

   [Service-Identity] Arkko, J. and P. Eronen, "Authenticated Service
                      Information for the Extensible Authentication
                      Protocol (EAP)", Work in Progress, October 2004.

   [RFC4086]          Eastlake, D., 3rd, Schiller, J., and S. Crocker,
                      "Randomness Requirements for Security", BCP 106,
                      RFC 4086, June 2005.

   [S3-020125]        Qualcomm, "Comments on draft EAP/SIM, 3rd
                      Generation Partnership Project document 3GPP TSG
                      SA WG3 Security S3#22, S3-020125", February 2002.

   [RFC3344]          Perkins, C., "IP Mobility Support for IPv4", RFC
                      3344, August 2002.

   [RFC2548]          Zorn, G., "Microsoft Vendor-specific RADIUS
                      Attributes ", RFC 2548, March 1999.

   [EAP-SRP]          Carlson, J., Aboba, B., and H. Haverinen, "EAP
                      SRP-SHA1 Authentication Protocol", Work in
                      Progress, July 2001.

   [GSM-Cloning]      Wagner, D., "GSM Cloning".  Web page about
                      COMP-128 version 1 vulnerabilities, available at
                      http://www.isaac.cs.berkeley.edu/isaac/gsm.html

   [Barkan-2003]      Barkan, E., Biham, E., and N. Keller, "Instant
                      Ciphertext-Only Cryptanalysis of GSM Encrypted
                      Communications".  available on-line at
                      http://cryptome.org/gsm-crack-bbk.pdf

   [Patel-2003]       Patel, S., "Analysis of EAP-SIM Session Key
                      Agreement".  Posted to the EAP mailing list 29
                      May,2003. http://
                      mail.frascone.com/pipermail/public/eap/2003-May/
                      001267.html
Top   ToC   RFC4186 - Page 81

Appendix A. Test Vectors

Test vectors for the NIST FIPS 186-2 pseudo-random number generator [PRF] are available at the following URL: http://csrc.nist.gov/encryption/dss/Examples-1024bit.pdf The following examples show the contents of EAP-SIM packets on full authentication and fast re-authentication.

A.1. EAP-Request/Identity

The first packet is a plain Identity Request: 01 ; Code: Request 00 ; Identifier: 0 00 05 ; Length: 5 octets 01 ; Type: Identity

A.2. EAP-Response/Identity

The client's identity is "1244070100000001@eapsim.foo", so it responds with the following packet: 02 ; Code: Response 00 ; Identifier: 0 00 20 ; Length: 32 octets 01 ; Type: Identity 31 32 34 34 ; "1244070100000001@eapsim.foo" 30 37 30 31 30 30 30 30 30 30 30 31 40 65 61 70 73 69 6d 2e 66 6f 6f
Top   ToC   RFC4186 - Page 82

A.3. EAP-Request/SIM/Start

The server's first packet looks like this: 01 ; Code: Request 01 ; Identifier: 1 00 10 ; Length: 16 octets 12 ; Type: EAP-SIM 0a ; EAP-SIM subtype: Start 00 00 ; (reserved) 0f ; Attribute type: AT_VERSION_LIST 02 ; Attribute length: 8 octets (2*4) 00 02 ; Actual version list length: 2 octets 00 01 ; Version: 1 00 00 ; (attribute padding)

A.4. EAP-Response/SIM/Start

The client selects a nonce and responds with the following packet: 02 ; Code: Response 01 ; Identifier: 1 00 20 ; Length: 32 octets 12 ; Type: EAP-SIM 0a ; EAP-SIM subtype: Start 00 00 ; (reserved) 07 ; Attribute type: AT_NONCE_MT 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) 01 23 45 67 ; NONCE_MT value 89 ab cd ef fe dc ba 98 76 54 32 10 10 ; Attribute type: AT_SELECTED_VERSION 01 ; Attribute length: 4 octets (1*4) 00 01 ; Version: 1
Top   ToC   RFC4186 - Page 83

A.5. EAP-Request/SIM/Challenge

Next, the server selects three authentication triplets (RAND1,SRES1,Kc1) = (10111213 14151617 18191a1b 1c1d1e1f, d1d2d3d4, a0a1a2a3 a4a5a6a7) (RAND2,SRES2,Kc2) = (20212223 24252627 28292a2b 2c2d2e2f, e1e2e3e4, b0b1b2b3 b4b5b6b7) (RAND3,SRES3,Kc3) = (30313233 34353637 38393a3b 3c3d3e3f, f1f2f3f4, c0c1c2c3 c4c5c6c7) Next, the MK is calculated as specified in Section 7*. MK = e576d5ca 332e9930 018bf1ba ee2763c7 95b3c712 And the other keys are derived using the PRNG: K_encr = 536e5ebc 4465582a a6a8ec99 86ebb620 K_aut = 25af1942 efcbf4bc 72b39434 21f2a974 MSK = 39d45aea f4e30601 983e972b 6cfd46d1 c3637733 65690d09 cd44976b 525f47d3 a60a985e 955c53b0 90b2e4b7 3719196a 40254296 8fd14a88 8f46b9a7 886e4488 EMSK = 5949eab0 fff69d52 315c6c63 4fd14a7f 0d52023d 56f79698 fa6596ab eed4f93f bb48eb53 4d985414 ceed0d9a 8ed33c38 7c9dfdab 92ffbdf2 40fcecf6 5a2c93b9 Next, the server selects a pseudonym and a fast re-authentication identity (in this case, "w8w49PexCazWJ&xCIARmxuMKht5S1sxR DqXSEFBEg3DcZP9cIxTe5J4OyIwNGVzxeJOU1G" and "Y24fNSrz8BP274jOJaF17WfxI8YO7QX0 0pMXk9XMMVOw7broaNhTczuFq53aEpOkk3L0dm@eapsim.foo", respectively).
Top   ToC   RFC4186 - Page 84
   The following plaintext will be encrypted and stored in the
   AT_ENCR_DATA attribute:

         84               ; Attribute type: AT_NEXT_PSEUDONYM
            13            ; Attribute length: 76 octets (19*4)
            00 46         ; Actual pseudonym length: 70 octets
            77 38 77 34 39 50 65 78 43 61 7a 57 4a 26 78 43
            49 41 52 6d 78 75 4d 4b 68 74 35 53 31 73 78 52
            44 71 58 53 45 46 42 45 67 33 44 63 5a 50 39 63
            49 78 54 65 35 4a 34 4f 79 49 77 4e 47 56 7a 78
            65 4a 4f 55 31 47
            00 00          ; (attribute padding)
         85                ; Attribute type: AT_NEXT_REAUTH_ID
            16             ; Attribute length: 88 octets (22*4)
            00 51          ; Actual re-auth identity length: 81 octets
            59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f
            4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30
            30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f
            61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b
            6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f
            6f
            00 00 00       ; (attribute padding)
         06                ; Attribute type: AT_PADDING
            03             ; Attribute length: 12 octets (3*4)
            00 00 00 00
            00 00 00 00
            00 00

   The EAP packet looks like this:

      01                   ; Code: Request
      02                   ; Identifier: 2
      01 18                ; Length: 280 octets
      12                   ; Type: EAP-SIM
         0b                ; EAP-SIM subtype: Challenge
         00 00             ; (reserved)
         01                ; Attribute type: AT_RAND
            0d             ; Attribute length: 52 octets (13*4)
            00 00          ; (reserved)
            10 11 12 13    ; first RAND
            14 15 16 17
            18 19 1a 1b
            1c 1d 1e 1f
            20 21 22 23    ; second RAND
            24 25 26 27
            28 29 2a 2b
            2c 2d 2e 2f
Top   ToC   RFC4186 - Page 85
            30 31 32 33    ; third RAND
            34 35 36 37
            38 39 3a 3b
            3c 3d 3e 3f
         81                ; Attribute type: AT_IV
            05             ; Attribute length: 20 octets (5*4)
            00 00          ; (reserved)
            9e 18 b0 c2    ; IV value
            9a 65 22 63
            c0 6e fb 54
            dd 00 a8 95
         82               ; Attribute type: AT_ENCR_DATA
            2d            ; Attribute length: 180 octets (45*4)
            00 00         ; (reserved)
            55 f2 93 9b bd b1 b1 9e a1 b4 7f c0 b3 e0 be 4c
            ab 2c f7 37 2d 98 e3 02 3c 6b b9 24 15 72 3d 58
            ba d6 6c e0 84 e1 01 b6 0f 53 58 35 4b d4 21 82
            78 ae a7 bf 2c ba ce 33 10 6a ed dc 62 5b 0c 1d
            5a a6 7a 41 73 9a e5 b5 79 50 97 3f c7 ff 83 01
            07 3c 6f 95 31 50 fc 30 3e a1 52 d1 e1 0a 2d 1f
            4f 52 26 da a1 ee 90 05 47 22 52 bd b3 b7 1d 6f
            0c 3a 34 90 31 6c 46 92 98 71 bd 45 cd fd bc a6
            11 2f 07 f8 be 71 79 90 d2 5f 6d d7 f2 b7 b3 20
            bf 4d 5a 99 2e 88 03 31 d7 29 94 5a ec 75 ae 5d
            43 c8 ed a5 fe 62 33 fc ac 49 4e e6 7a 0d 50 4d
         0b                ; Attribute type: AT_MAC
            05             ; Attribute length: 20 octets (5*4)
            00 00          ; (reserved)
            fe f3 24 ac    ; MAC value
            39 62 b5 9f
            3b d7 82 53
            ae 4d cb 6a

   The MAC is calculated over the EAP packet above (with MAC value set
   to zero), followed by the NONCE_MT value (a total of 296 bytes).
Top   ToC   RFC4186 - Page 86

A.6. EAP-Response/SIM/Challenge

The client's response looks like this: 02 ; Code: Response 02 ; Identifier: 2 00 1c ; Length: 28 octets 12 ; Type: EAP-SIM 0b ; EAP-SIM subtype: Challenge 00 00 ; (reserved) 0b ; Attribute type: AT_MAC 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) f5 6d 64 33 ; MAC value e6 8e d2 97 6a c1 19 37 fc 3d 11 54 The MAC is calculated over the EAP packet above (with MAC value set to zero), followed by the SRES values (a total of 40 bytes).

A.7. EAP-Success

The last packet is an EAP-Success: 03 ; Code: Success 02 ; Identifier: 2 00 04 ; Length: 4 octets

A.8. Fast Re-authentication

When performing fast re-authentication, the EAP-Request/Identity packet is the same as usual. The EAP-Response/Identity contains the fast re-authentication identity (from AT_ENCR_DATA attribute above): 02 ; Code: Response 00 ; Identifier: 0 00 56 ; Length: 86 octets 01 ; Type: Identity 59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f 4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30 30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f 61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b 6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f 6f
Top   ToC   RFC4186 - Page 87

A.9. EAP-Request/SIM/Re-authentication

The server recognizes the reauthentication identity, so it will respond with EAP-Request/SIM/Re-authentication. It retrieves the associated counter value, generates a nonce, and picks a new reauthentication identity (in this case, "uta0M0iyIsMwWp5TTdSdnOLvg2XDVf21OYt1vnfiMcs5dnIDHOIFVavIRzMR yzW6vFzdHW@eapsim.foo"). The following plaintext will be encrypted and stored in the AT_ENCR_DATA attribute. Note that AT_PADDING is not used because the length of the plaintext is a multiple of 16 bytes. 13 ; Attribute type: AT_COUNTER 01 ; Attribute length: 4 octets (1*4) 00 01 ; Counter value 15 ; Attribute type: AT_NONCE_S 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) 01 23 45 67 ; NONCE_S value 89 ab cd ef fe dc ba 98 76 54 32 10 85 ; Attribute type: AT_NEXT_REAUTH_ID 16 ; Attribute length: 88 octets (22*4) 00 51 ; Actual re-auth identity length: 81 octets 75 74 61 30 4d 30 69 79 49 73 4d 77 57 70 35 54 54 64 53 64 6e 4f 4c 76 67 32 58 44 56 66 32 31 4f 59 74 31 76 6e 66 69 4d 63 73 35 64 6e 49 44 48 4f 49 46 56 61 76 49 52 7a 4d 52 79 7a 57 36 76 46 7a 64 48 57 40 65 61 70 73 69 6d 2e 66 6f 6f 00 00 00 ; (attribute padding)
Top   ToC   RFC4186 - Page 88
   The EAP packet looks like this:

      01                   ; Code: Request
      01                   ; Identifier: 1
      00 a4                ; Length: 164 octets
      12                   ; Type: EAP-SIM
         0d                ; EAP-SIM subtype: Re-authentication
         00 00             ; (reserved)
         81                ; Attribute type: AT_IV
            05             ; Attribute length: 20 octets (5*4)
            00 00          ; (reserved)
            d5 85 ac 77    ; IV value
            86 b9 03 36
            65 7c 77 b4
            65 75 b9 c4
         82                ; Attribute type: AT_ENCR_DATA
            1d             ; Attribute length: 116 octets (29*4)
            00 00          ; (reserved)
            68 62 91 a9 d2 ab c5 8c aa 32 94 b6 e8 5b 44 84
            6c 44 e5 dc b2 de 8b 9e 80 d6 9d 49 85 8a 5d b8
            4c dc 1c 9b c9 5c 01 b9 6b 6e ca 31 34 74 ae a6
            d3 14 16 e1 9d aa 9d f7 0f 05 00 88 41 ca 80 14
            96 4d 3b 30 a4 9b cf 43 e4 d3 f1 8e 86 29 5a 4a
            2b 38 d9 6c 97 05 c2 bb b0 5c 4a ac e9 7d 5e af
            f5 64 04 6c 8b d3 0b c3 9b e5 e1 7a ce 2b 10 a6
         0b                ; Attribute type: AT_MAC
            05             ; Attribute length: 20 octets (5*4)
            00 00          ; (reserved)
            48 3a 17 99    ; MAC value
            b8 3d 7c d3
            d0 a1 e4 01
            d9 ee 47 70

   The MAC is calculated over the EAP packet above (with MAC value set
   to zero; a total of 164 bytes).

   Finally, the server derives new keys.  The XKEY' is calculated as
   described in Section 7*:

   XKEY' = 863dc120 32e08343 c1a2308d b48377f6 801f58d4
Top   ToC   RFC4186 - Page 89
   The new MSK and EMSK are derived using the PRNG (note that K_encr and
   K_aut stay the same).

         MSK   =  6263f614 973895e1 335f7e30 cff028ee
                  2176f519 002c9abe 732fe0ef 00cf167c
                  756d9e4c ed6d5ed6 40eb3fe3 8565ca07
                  6e7fb8a8 17cfe8d9 adbce441 d47c4f5e
         EMSK  =  3d8ff786 3a630b2b 06e2cf20 9684c13f
                  6b82f992 f2b06f1b 54bf51ef 237f2a40
                  1ef5e0d7 e098a34c 533eaebf 34578854
                  b7721526 20a777f0 e0340884 a294fb73

A.10. EAP-Response/SIM/Re-authentication

The client's response includes the counter as well. The following plaintext will be encrypted and stored in the AT_ENCR_DATA attribute: 13 ; Attribute type: AT_COUNTER 01 ; Attribute length: 4 octets (1*4) 00 01 ; Counter value 06 ; Attribute type: AT_PADDING 03 ; Attribute length: 12 octets (3*4) 00 00 00 00 00 00 00 00 00 00 The EAP packet looks like this: 02 ; Code: Response 01 ; Identifier: 1 00 44 ; Length: 68 octets 12 ; Type: EAP-SIM 0d ; EAP-SIM subtype: Re-authentication 00 00 ; (reserved) 81 ; Attribute type: AT_IV 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) cd f7 ff a6 ; IV value 5d e0 4c 02 6b 56 c8 6b 76 b1 02 ea 82 ; Attribute type: AT_ENCR_DATA 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) b6 ed d3 82 79 e2 a1 42 3c 1a fc 5c 45 5c 7d 56
Top   ToC   RFC4186 - Page 90
         0b                ; Attribute type: AT_MAC
            05             ; Attribute length: 20 octets (5*4)
            00 00          ; (reserved)
            fa f7 6b 71    ; MAC value
            fb e2 d2 55
            b9 6a 35 66
            c9 15 c6 17

   The MAC is calculated over the EAP packet above (with MAC value set
   to zero), followed by the NONCE_S value (a total of 84 bytes).

   The next packet will be EAP-Success:

      03                   ; Code: Success
      01                   ; Identifier: 1
      00 04                ; Length: 4 octets

Appendix B. Pseudo-Random Number Generator

The "|" character denotes concatenation, and "^" denotes exponentiation. Step 1: Choose a new, secret value for the seed-key, XKEY Step 2: In hexadecimal notation let t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 This is the initial value for H0|H1|H2|H3|H4 in the FIPS SHS [SHA-1] Step 3: For j = 0 to m - 1 do 3.1 XSEED_j = 0 /* no optional user input */ 3.2 For i = 0 to 1 do a. XVAL = (XKEY + XSEED_j) mod 2^b b. w_i = G(t, XVAL) c. XKEY = (1 + XKEY + w_i) mod 2^b 3.3 x_j = w_0|w_1
Top   ToC   RFC4186 - Page 91

Authors' Addresses

Henry Haverinen (editor) Nokia Enterprise Solutions P.O. Box 12 FIN-40101 Jyvaskyla Finland EMail: henry.haverinen@nokia.com Joseph Salowey (editor) Cisco Systems 2901 Third Avenue Seattle, WA 98121 USA Phone: +1 206 256 3380 EMail: jsalowey@cisco.com
Top   ToC   RFC4186 - Page 92
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).