idnits 2.17.1 draft-smith-opentoken-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 533. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 11, 2008) is 5736 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Smith 3 Internet-Draft Individual 4 Intended status: Informational P. Motykowski 5 Expires: February 12, 2009 Y. Faruqi 6 PingID 7 P. Saint-Andre, Ed. 8 Individual 9 August 11, 2008 11 OpenToken 12 draft-smith-opentoken-02 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on February 12, 2009. 39 Abstract 41 This document describes OpenToken (OTK), a format for the 42 lightweight, secure, cross-application exchange of key-value pairs. 43 The format is designed primarily for use as an HTTP cookie or query 44 parameter, but can also be used in other scenarios that require a 45 compact, application-neutral token. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Token Layout . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.3. Standard Key-Value Pairs . . . . . . . . . . . . . . . . . 6 57 4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 8 59 6. Canonical Test Data . . . . . . . . . . . . . . . . . . . . . 9 60 6.1. Test Case 1: AES-128 . . . . . . . . . . . . . . . . . . . 9 61 6.2. Test Case 2: AES-256 . . . . . . . . . . . . . . . . . . . 10 62 6.3. Test Case 3: 3DES-168 . . . . . . . . . . . . . . . . . . 10 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 68 Intellectual Property and Copyright Statements . . . . . . . . . . 13 70 1. Introduction 72 1.1. Motivation 74 This document describes OpenToken (OTK), a format for the 75 lightweight, secure, cross-application exchange of key-value pairs 76 between applications that use HTTP (see [RFC2616]) as the transport 77 protocol. The format is designed primarily for use as an HTTP cookie 78 (see [RFC2965]) or query parameter, but can also be used in other 79 scenarios that require a compact, application-neutral token. 81 The OpenToken technology is not designed to encapsulate formal 82 identity assertions (for which see [SAML]) or authentication 83 credentials (for which see [SASL]). Instead, OpenToken is designed 84 to encapsulate basic name-value pairs for exchange between 85 applications that use HTTP as the transport protocol. 87 Consider the example of a web application that receives information 88 from an end user via a web browser and subsequently shares that 89 information with a backend system such as a single-sign-on (SSO) 90 application. 92 +---------+ 93 | browser | 94 +---------+ 95 | 96 | HTML form 97 | 98 +---------+ +---------+ 99 | web app | ---------> | SSO app | 100 +---------+ (OTK) +---------+ 102 Naturally the web application or the single-sign-on application could 103 exchange the same information with other applications (e.g., billing, 104 customer service, enterprise resource planning) or push the 105 information back to the end user via an HTTP cookie. The end user 106 could also share that same information with other web applications 107 (e.g., the web application could store the information on the end 108 user's browser via an HTTP cookie, which could be shared with other 109 applications). 111 The use of a consistent data format enables a more seamless exchange 112 of information between applications (e.g., by removing the need to 113 translate between different application-specific data formats). 115 1.2. Terminology 117 The following keywords are to be interpreted as described in 118 [RFC2119]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; 119 "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", 120 "OPTIONAL". 122 2. Token Layout 124 The OpenToken format is specified in the following table. 126 +------------+----------+-------------------------+ 127 | Byte Range | Length | Description | 128 +------------+----------+-------------------------+ 129 | 0..2 | 3 | 'O','T','K' literal | 130 | 3 | 1 | Version identifier | 131 | 4 | 1 | Cipher suite identifier | 132 | 5..24 | 20 | SHA-1 HMAC | 133 | 25 | 1 | IV length | 134 | 26..x | x-26 | IV | 135 | x+1 | 1 | Key Info length | 136 | x+2..y | y-(x+2) | Key info | 137 | y+1..y+3 | 2 | Payload length | 138 | y+4..z | z-(y+4) | Payload | 139 | TOTAL | 29+x+y+z | N/A | 140 +------------+----------+-------------------------+ 142 The following notes apply to the foregoing token parameters: 144 o The datatype for the version identifier, cipher suite identifier, 145 IV length, and Key Info length is unsigned byte. 146 o The initialization vector (IV) has a maximum length of 255 bytes. 147 This field is OPTIONAL and MAY have a length of 0 (IV length) to 148 indicate that no IV is available for this token. For details 149 about initialization vectors, see [RFC2898]. 150 o The payload is a series of key-value pairs, as described under 151 Section 5. 152 o The payload has a maximum (compressed) length of 64k bytes. While 153 this format supports a payload of 64k bytes, deployment scenarios 154 that pass the token using HTTP (either as a query parameter or 155 cookie) SHOULD limit the token length to less than 4k for optimal 156 compatibility. 157 o The [HMAC] used in this version of OpenToken is based on the SHA-1 158 hashing algorithm specified in [SHA]. See Section 7 for further 159 information about the security characteristics of this algorithm. 161 o The Key Info field provides a place to store meta-data describing 162 the key used to encrypt the payload. For example, it can contain 163 a cryptographic hash of the key, or some other identifier, so that 164 the token recipient can select the appropriate key for decryption. 165 This field is OPTIONAL and MAY have a length of 0 (Key Info 166 length) to indicate that no meta-data is available for this token. 168 Given the limited scope of applicability and the desire for a 169 lightweight exchange format, OpenToken uses a binary format rather 170 than a more generic data-description language such as [ASN.1] or 171 [XML]. 173 3. Processing Rules 175 3.1. Encoding 177 Generating an OTK involves the following steps: 179 1. Generate the payload. 180 2. Select a cipher suite and generate a corresponding IV. 181 3. Initialize an [HMAC] using the SHA-1 algorithm specified in [SHA] 182 and the following data (order is significant): 183 1. OTK version 184 2. Cipher suite value 185 3. IV value (if present) 186 4. Key Info value (if present) 187 5. Payload length (2 bytes, network order) 188 4. Update the SHA-1 HMAC (from the previous step) using the clear- 189 text payload. 190 5. Compress the payload using the DEFLATE specification in 191 accordance with [RFC1950] and [RFC1951]. 192 6. Encrypt the compressed payload using the selected cipher suite. 193 7. Construct the binary structure representing the OTK; place the 194 MAC, IV, key info and cipher-text within the structure. 195 8. Base 64 encode the entire binary structure, following the rules 196 in Section 4 of [RFC4648] and ensuring that the padding bits are 197 set to zero. 198 9. Replace all Base 64 padding characters "=" with "*" (RFC 4648 199 does not account for the problems that Base64 padding causes when 200 used as a cookie; this step corrects that issue). 202 3.2. Decoding 204 Processing an OTK involves the following steps: 206 1. Replace the "*" padding characters (see Encoding section, step 207 9) with standard Base 64 "=" characters. 208 2. Base 64 decode the OTK, following the rules in Section 4 of 209 [RFC4648] and ensuring that the padding bits are set to zero. 210 3. Validate the OTK header literal and version. 211 4. Extract the Key Info (if present) and select a key for 212 decryption. 213 5. Decrypt the payload cipher-text using the selected cipher suite. 214 6. Decompress the decrypted payload, in accordance with [RFC1950] 215 and [RFC1951]. 216 7. Initialize an [HMAC] using the SHA-1 algorithm specified in 217 [SHA] and the following data (order is significant): 218 1. OTK version 219 2. Cipher suite value 220 3. IV value (if present) 221 4. Key Info value (if present) 222 5. Payload length (2 bytes, network order) 223 8. Update the HMAC from the previous step with the clear-text 224 payload (after decompressing). 225 9. Compare the HMAC from step 8 with the HMAC received in the OTK. 226 If they do not match, halt processing. 227 10. Process the payload. 229 3.3. Standard Key-Value Pairs 231 The token payload contains key-value pairs, as described under 232 Section 5. These data pairs are used to describe the token presenter 233 and can vary from application to application. In the interest of 234 basic interoperability when exchanging an OTK, there is a small set 235 of standardized data pairs. 237 +-----------------+----------------------+---------------------------+ 238 | Key Name | Value Format | Description | 239 +-----------------+----------------------+---------------------------+ 240 | subject | string | Primary identifier for | 241 | | | the token holder. | 242 +-----------------+----------------------+---------------------------+ 243 | not-before | ISO 8601 datetime; | Datetime when token was | 244 | | yyyy-MM-ddTHH:mm:ssZ | created; a token received | 245 | | | before this datetime MUST | 246 | | | be rejected as invalid. | 247 +-----------------+----------------------+---------------------------+ 248 | not-on-or-after | ISO 8601 datetime; | Datetime at which token | 249 | | yyyy-MM-ddTHH:mm:ssZ | will expire; a token | 250 | | | received on or after this | 251 | | | datetime MUST be rejected | 252 | | | as invalid. | 253 +-----------------+----------------------+---------------------------+ 254 | renew-until | ISO 8601 datetime; | Datetime at which token | 255 | | yyyy-MM-ddTHH:mm:ssZ | MUST NOT automatically | 256 | | | re-issued without further | 257 | | | authentication; this can | 258 | | | be viewed as a "session" | 259 | | | lifetime. | 260 +-----------------+----------------------+---------------------------+ 262 The following rules apply: 264 o All datetimes MUST be calculated relative to UTC (i.e., no 265 timezone offsets). 266 o The predefined key-value pairs MUST NOT be used for any purpose 267 other than what is defined above and SHOULD be included with all 268 issued OTKs. 270 4. Cipher Suites 272 A cipher suite groups a cryptographic cipher with a specific key 273 size, cipher mode, and padding scheme. This grouping provides a 274 convenient way of representing these inter-dependent options and also 275 helps the implementor understand the exact cryptographic requirements 276 for a given OTK. 278 +----+--------+----------+------+---------+-----------+ 279 | ID | Cipher | Key Size | Mode | Padding | IV Length | 280 +----+--------+----------+------+---------+-----------+ 281 | 0 | Null | N/A | N/A | N/A | 0 | 282 | 1 | AES | 256 bits | CBC | PKCS 5 | 16 | 283 | 2 | AES | 128 bits | CBC | PKCS 5 | 16 | 284 | 3 | 3DES | 168 bits | CBC | PKCS 5 | 8 | 285 +----+--------+----------+------+---------+-----------+ 287 Note: 289 o The Null cipher is meant only for testing purposes. It MUST NOT 290 be used in production environments, since the payload would be 291 passed in the clear. When using the Null cipher, the SHA-1 MAC 292 value MUST be replaced with a standard SHA-1 hash of the 293 uncompressed payload. 294 o For cipher suites that do not require an IV, the IV length MAY be 295 zero. 296 o For information regarding PKCS #5 padding, see [RFC2898]. 298 5. Payload Format 300 OTK uses a simple, line-based format for encoding the key-value pairs 301 in the payload. The format is encoded with UTF-8 and thus is 302 guaranteed to support the transport of multi-byte characters. The 303 syntax for an OpenToken is defined as follows using the Augmented 304 Backus-Naur Form as specified in [ABNF]. 306 line = key "=" value CRLF 307 key = [whitespace] identifier [whitespace] 308 whitespace = HTAB / SP 309 identifier = anychar 310 value = [whitespace] data [whitespace] / 311 [whitespace] quoted-data [whitespace] 312 data = anychar / "" 313 ; all characters 314 ; can be empty to represent null values 315 quoted-data = "\"" anychar "\"" / 316 "\'" anychar "\'" 317 ; double and single quotes must be 318 ; escaped via preceding backslash 319 anychar = %x20-%x3C / %x3E-%x7E / %xA0-D7FF / %xF900-FDCF 320 / %xFDF0-FFEF / %x10000-1FFFD / %x20000-2FFFD 321 / %x30000-3FFFD / %x40000-4FFFD / %x50000-5FFFD 322 / %x60000-6FFFD / %x70000-7FFFD / %x80000-8FFFD 323 / %x90000-9FFFD / %xA0000-AFFFD / %xB0000-BFFFD 324 / %xC0000-CFFFD / %xD0000-DFFFD / %xE1000-EFFFD 325 ; any Unicode character except "=" 327 The following rules apply: 329 o Key names might not be unique. OpenToken supports multiple values 330 for a key name by simply adding another key-value pair. 331 o Key names are case-sensitive. It is RECOMMENDED that all key 332 names be lowercase and use hyphens to separate "words". 333 o If the value for a key is or includes a Uniform Resource 334 Identifier (URI), the characters "&" and "=" SHOULD be percent- 335 encoded according to the rules specified in [URI]. 337 6. Canonical Test Data 339 It is important to ensure interoperability across tokens generated by 340 different implementations/languages. The following test cases can be 341 used to test an implementation and ensure that it generates properly 342 encoded tokens. These tests are not exhaustive, but do cover the 343 basic cipher suites. 345 For each test case, the key that was used to generate the output is 346 included in base64 encoding. The generated token is also base64 347 encoded, as specified above. 349 Each token has two name-value pairs present: 351 foo = bar 352 bar = baz 354 Note: In the following test data, the tokens are wrapped across two 355 lines to fit and the "\" character is used to denote the point of 356 line wrapping. 358 6.1. Test Case 1: AES-128 360 key: 362 a66C9MvM8eY4qJKyCXKW+w== 364 token: 366 UFRLAQK9THj0okLTUB663QrJFg5qA58IDhAb93ondvcx7sY6s44eszNqAAAga5W8Dc\ 367 4XZwtsZ4qV3_lDI-Zn2_yadHHIhkGqNV5J9kw* 369 6.2. Test Case 2: AES-256 371 key: 373 a66C9MvM8eY4qJKyCXKW+19PWDeuc3thDyuiumak+Dc= 375 token: 377 UFRLAQEujlLGEvmVKDKyvL1vaZ27qMYhTxDSAZwtaufqUff7GQXTjvWBAAAgJJGPta\ 378 7VOITap4uDZ_OkW_Kt4yYZ4BBQzw_NR2CNE-g* 380 6.3. Test Case 3: 3DES-168 382 key: 384 a66C9MvM8eY4qJKyCXKW+19PWDeuc3th 386 token: 388 UFRLAQNoCsuAwybXOSBpIc9ZvxQVx_3fhghqSjy-pNJpfgAAGGlGgJ79NhX43lLRXA\ 389 b9Mp5unR7XFWopzw** 391 7. Security Considerations 393 Recent research has shown that in select cases it is possible to 394 compromise the hashes produced by the SHA-1 hashing algorithm (see 395 [RFC4270]). However, the use to which SHA-1 is put in OpenToken, 396 coupled with employment of a symmetric cipher key, will likely 397 minimize the applicability of the attacks described in the 398 literature. Furthermore, current estimates suggest that even with 399 the recently-discovered attack, it would still take one year of 400 computing by a government-sized entity to produce a collision. 402 Tokens SHOULD be exchanged over a secure transport (e.g., HTTP Over 403 TLS as described in [RFC2818]) to minimize the possibility that a 404 token can be intercepted by a man-in-the-middle. 406 8. References 408 8.1. Normative References 410 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 411 Specifications: ABNF", RFC 4234, October 2005. 413 [HMAC] National Institute of Standards and Technology, "The 414 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 415 198, March 2002, . 418 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 419 Specification version 3.3", RFC 1950, May 1996. 421 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 422 version 1.3", RFC 1951, May 1996. 424 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 425 Encodings", RFC 4648, October 2006. 427 [SHA] National Institute of Standards and Technology, "Secure 428 Hash Standard", FIPS PUB 180-2, August 2002, . 432 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 433 Resource Identifier (URI): Generic Syntax", STD 66, 434 RFC 3986, January 2005. 436 8.2. Informative References 438 [ASN.1] CCITT, "Recommendation X.208: Specification of Abstract 439 Syntax Notation One (ASN.1)", 1988. 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 445 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 446 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 448 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 450 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 451 Specification Version 2.0", RFC 2898, September 2000. 453 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 454 Mechanism", RFC 2965, October 2000. 456 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 457 Hashes in Internet Protocols", RFC 4270, November 2005. 459 [SAML] Cantor, S., Kemp, J., Philpott, R., and E. Maler, 460 "Assertions and Protocol for the OASIS Security Assertion 461 Markup Language (SAML) V2.0", OASIS Standard saml-core- 462 2.0-os, March 2005. 464 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 465 Security Layer (SASL)", RFC 4422, June 2006. 467 [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., 468 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth 469 Edition)", World Wide Web Consortium Recommendation REC- 470 xml-20060816, August 2006, 471 . 473 Authors' Addresses 475 Dave Smith 476 Individual 478 Email: dizzyd@dizzyd.com 480 Peter Motykowski 481 Ping Identity 483 Email: peter@motyka.org 485 Yasir Faruqi 486 Ping Identity 488 Email: yfaruqi@pingidentity.com 490 Peter Saint-Andre (editor) 491 Individual 493 Email: stpeter@jabber.org 495 Full Copyright Statement 497 Copyright (C) The IETF Trust (2008). 499 This document is subject to the rights, licenses and restrictions 500 contained in BCP 78, and except as set forth therein, the authors 501 retain all their rights. 503 This document and the information contained herein are provided on an 504 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 505 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 506 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 507 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 508 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 509 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 511 Intellectual Property 513 The IETF takes no position regarding the validity or scope of any 514 Intellectual Property Rights or other rights that might be claimed to 515 pertain to the implementation or use of the technology described in 516 this document or the extent to which any license under such rights 517 might or might not be available; nor does it represent that it has 518 made any independent effort to identify any such rights. Information 519 on the procedures with respect to rights in RFC documents can be 520 found in BCP 78 and BCP 79. 522 Copies of IPR disclosures made to the IETF Secretariat and any 523 assurances of licenses to be made available, or the result of an 524 attempt made to obtain a general license or permission for the use of 525 such proprietary rights by implementers or users of this 526 specification can be obtained from the IETF on-line IPR repository at 527 http://www.ietf.org/ipr. 529 The IETF invites any interested party to bring to its attention any 530 copyrights, patents or patent applications, or other proprietary 531 rights that may cover technology that may be required to implement 532 this standard. Please address the information to the IETF at 533 ietf-ipr@ietf.org.