idnits 2.17.1 draft-schilcher-mobike-pfkey-extension-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 585. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (July 17, 2005) is 6855 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '11' is defined on line 522, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2367 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-08) exists of draft-ietf-mobike-design-02 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IKEv2 Mobility and Multihoming U. Schilcher 3 (mobike) H. Tschofenig 4 Internet-Draft F. Muenz 5 Expires: January 18, 2006 Siemens AG 6 July 17, 2005 8 MOBIKE Extensions for PF_KEY 9 draft-schilcher-mobike-pfkey-extension-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 18, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 PF_KEY is a generic key management API used for communication between 43 a trusted user level key management daemon and a key engine within 44 the operating system. With the extension of IKEv2 for mobility and 45 multihoming (MOBIKE) the existing capabilities of PF_KEY with regard 46 to the creation, maintenance and deletion of security associations 47 became insufficient. This document defines an extension to update an 48 entity in the security association database. Additionally, it is 49 necessary to reflect the newly offered integrity and encryption 50 algorithms with IKEv2 in PF_KEY. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. IPsec SA Update . . . . . . . . . . . . . . . . . . . . . . 5 57 4. SA Extension . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. SPD Update . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 6. Algorithm Types . . . . . . . . . . . . . . . . . . . . . . 13 60 7. Traffic Selector Extensions . . . . . . . . . . . . . . . . 15 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 62 9. Security Considerations . . . . . . . . . . . . . . . . . . 17 63 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 65 11.1 Normative References . . . . . . . . . . . . . . . . . . 19 66 11.2 Informative References . . . . . . . . . . . . . . . . . 19 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 68 Intellectual Property and Copyright Statements . . . . . . . 21 70 1. Introduction 72 PF_KEY [1] is a generic key management API used for communication 73 between a trusted user level key management daemon and a key engine 74 within the operating system. With the extension of IKEv2 for 75 mobility and multihoming (MOBIKE) [12] the existing capabilities of 76 PF_KEY with regard to the creation, maintenance and deletion of 77 security associations became insufficient. If an IKEv2 78 implementation [13] supports MOBIKE, some additional interaction with 79 the SAD and the SPD has to be provided. This includes additional 80 operations on the security policy database (SPD), such as creation, 81 update and deletion of SPD entries, and the possibility to update 82 addresses for already existing SAs in the security association 83 database (SAD). Since the PF_KEY interface in the current version 84 does not support this operations, some extensions have to be defined. 86 This document is partially based on PF_KEY extensions provided the 87 KAME stack (see also [14]), which go beyond those described in [1]. 88 The authors think that it is necessary to update the original RFC 89 2367 PF_KEY version to reflect the state-of-the-art implementations. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [2]. 97 3. IPsec SA Update 99 The first extension allows an IKEv2 implementation to update the 100 addresses of an existing security association (SA) dynamically. 101 Updating IPsec SAs is one of the side-effect of the IKE-SA update, a 102 feature provided by MOBIKE [12]. PF_KEY defines a number of 103 messages, namely SADB_GETSPI, SADB_UPDATE, SADB_ADD, SADB_DELETE, 104 SADB_GET, SADB_ACQUIRE, SADB_REGISTER, SADB_EXPIRE, SADB_FLUSH and 105 SADB_DUMP, for interaction between the key management daemon and the 106 key engine in the operating system. 108 In Section 3.1.2 of [1] an SADB_UPDATE message is described for 109 updating all data stored for an existing SA. The only parameters, 110 which cannot be updated using an SADB_UPDATE message, are the 111 Security Parameter Index (SPI), the source and destination IP 112 addresses. The reason for this design decision might be based on the 113 IPsec SA identification, which included these parameters to uniquely 114 select a given security association. This aspect can, however, be 115 seen as historic. In IKEv2, without the use of MOBIKE, theses 116 parameters would not change. 118 To allow an IKEv2 key management daemon to change the addresses of an 119 existing SA, a new message type has to be introduced: 120 SADB_X_ADDRUPDATE. The notation of SADB_X is intended to outline an 121 extention to the current API defined in [1]. Required symbols or 122 structures in the PF_KEYv2 name space that are not described in [1] 123 should therefore start with "SADB_X_" or "sadb_x_". 125 The format of the SADB_X_ADDRUPDATE message is: 127 129 The kernel responds with a message of the form: 131 133 The meaning of the payloads of the message is the following: "base" 134 defines the default message header, "SA(*)" identifies the security 135 association to be updated, where (*) indicates that the SA payload 136 contains only the SPI of it, "address(SD)" contains the source and 137 the destination addresses of the existing SA and "new_address(SD)" 138 the new source and destination addresses. For a more detailed 139 description of the payloads see [1]. For the new_address(SD) 140 attribute new payload types SADB_X_EXT_NEW_ADDRESS_SRC and 141 SADB_X_EXT_NEW_ADDRESS_DST are needed. These payloads have the same 142 content as the SADB_EXT_ADDRESS_SRC and SADB_EXT_ADDRESS_DST 143 payloads. 145 If the kernel receives a SADB_X_ADDRUPDATE message it immediately 146 updates the SA identified by the SPI in the message. If more than 147 one SA has to be updated, several SADB_X_ADDRUPDATE messages have to 148 be sent since each SA payload can only contain one SPI. 150 In an error case, like for instance a malformed message, the kernel 151 will respond with: 153 155 The "errno" field of the message will provide further information 156 about the error. 158 4. SA Extension 160 In case a protected packet arrives with an unknown SPI value, for 161 which no corresponding SA exists, the kernel actively sends a 162 SADB_ACQUIRE to all listening applications. Using the information 163 given in the SADB_ACQUIRE, the applications are able to quickly 164 create a SA, while the triggering packet is still in the kernel 165 buffer. The important information that are missing, are the traffic 166 selector (TS) addresses, which are negotiated by IKEv2 using the TS 167 payloads. 169 Since the TS addresses are only stored inside the SPD, they have to 170 be read from there (see section Section 5). For that purpose the ID, 171 which identifies the SPD entry, to which the new SA corresponds, has 172 to be known. The proposed way to pass that ID from the kernel to the 173 IKEv2 implementation is in using the following extension of the 174 PF_KEY interface. 176 An SA2 payload has to be included in the SADB_ACQUIRE message, which 177 has to following content: 179 struct sadb_x_sa2 { 180 uint16_t sadb_x_sa2_len; 181 uint16_t sadb_x_sa2_exttype; 182 uint8_t sadb_x_sa2_mode; 183 uint8_t sadb_x_sa2_reserved1; 184 uint16_t sadb_x_sa2_reserved2; 185 uint32_t sadb_x_sa2_sequence; 186 uint32_t sadb_x_sa2_reqid; 187 } __attribute__((packed)); 188 /* sizeof(struct sadb_x_sa2) == 16 */ 190 sadb_x_sa2_len: 192 The sadb_x_sa2_len contains the length of the structure in 8 Byte 193 blocks. 195 sadb_x_sa2_exttype: 197 This field contains the value identifying the SADB_X_SA2 payload. 199 sadb_x_sa2_mode: 201 The sadb_x_sa2_mode field identifies the IPsec mode (i.e., tunnel 202 or transport mode). 204 sadb_x_sa2_sequence: 206 The sadb_x_sa2_sequence field contains the ID of the corresponding 207 SPD entry. 209 sadb_x_sa2_reqid: 211 The request ID for that message. 213 This payload can also be added to SADB_ADD and SADB_UPDATE messages 214 to tell the kernel whether the SA to be generated is a transport or a 215 tunnel mode SA. If no SADB_X_SA2 payload is present, all SAs created 216 will only support tunnel mode. 218 5. SPD Update 220 For manipulating SPD entries, new PF_KEY messages have to be 221 introduced (see also the KAME IPsec implementation). 223 Note that specifying SPD updates is problematic since the KAME IPsec 224 extensions have never been standardized. As a consequence, this text 225 does not extend PF_KEY [1] itself. 227 These message types are quite similar to the message types used to 228 manipulate the entries in the SAD. The following new message types 229 are needed: 231 SADB_X_SPDADD: 233 To add a new entry to the SPD, the key management daemon needs to 234 send a SADB_X_SPDADD message to the kernel. The format of the 235 message is: 237 239 The kernel responds with a message of the form: 241 243 The meaning of the payloads, except for the policy payload, can be 244 found in [1]. The policy payload contains all specific 245 information about the new entry: 247 struct sadb_x_policy { 248 uint16_t sadb_x_policy_len; 249 uint16_t sadb_x_policy_exttype; 250 uint16_t sadb_x_policy_type; 251 uint8_t sadb_x_policy_dir; 252 uint8_t sadb_x_policy_reserved; 253 uint32_t sadb_x_policy_id; 254 uint32_t sadb_x_policy_reserved2; 255 } __attribute__((packed)); 256 /* sizeof(struct sadb_x_policy) == 16 */ 258 The sadb_x_policy_len field contains the length of the payload in 259 8 Byte blocks and sadb_x_policy_exttype contains the value 260 SADB_X_SPDADD. The type of the SA is indicated by the 261 sadb_x_policy_type field (e.g., IPsec SA) and the 262 sadb_x_policy_dir field indicates the direction of the SA (the 263 possibilities are IPSEC_DIR_INBOUND, IPSEC_DIR_OUTBOUND and 264 IPSEC_DIR_FWD). The sadb_x_policy_id field contains a value which 265 is unique for each SPD entry. It should be set to zero for a 266 SADB_X_SPDADD message, since the kernel is going to fill this 267 value in. This structure is followed by one or more ipsecrequest 268 structures, one for each protocol used by the new SPD entry: 270 struct sadb_x_ipsecrequest { 271 uint16_t sadb_x_ipsecrequest_len; 272 uint16_t sadb_x_ipsecrequest_proto; 273 uint8_t sadb_x_ipsecrequest_mode; 274 uint8_t sadb_x_ipsecrequest_level; 275 uint16_t sadb_x_ipsecrequest_reserved1; 276 uint32_t sadb_x_ipsecrequest_reqid; 277 uint32_t sadb_x_ipsecrequest_reserved2; 278 } __attribute__((packed)); 279 /* sizeof(struct sadb_x_ipsecrequest) == 16 */ 281 sadb_x_ipsecrequest_len: 283 The sadb_x_ipsecrequest_len again contains the length of the 284 structure including optional extensions, but this time in 285 bytes. 287 sadb_x_ipsecrequest_proto: 289 The sadb_x_ipsecrequest_proto field identifies the protocol 290 used for the current structure (e.g., ESP or AH). 292 sadb_x_ipsecrequest_mode: 294 The sadb_x_ipsecrequest_mode field identifies the IPsec mode 295 (i.e., tunnel or transport mode), which can be different for 296 each protocol. 298 sadb_x_ipsecrequest_level: 300 The sadb_x_ipsecrequest_level field contains one of the 301 following values: 'default', 'use', 'require' or 'unique'. It 302 defines how and when a corresponding SA is used. The value 303 'use' means that an SA is used if available, otherwise the 304 kernel keeps its normal operation. If 'require' is specified, 305 it means that an SA is required for each packet matching to the 306 policy entry. The value 'unique' has the same meaning as 307 require except that the policy entry is bound to exactly one 308 outbound SA. 310 sadb_x_ipsecrequest_reqid: 312 An ID for that SA can be passed to the kernel in the 313 sadb_x_ipsecrequest_reqid field. 315 If tunnel mode is specified, the sadb_x_ipsecrequest structure is 316 followed by two sockaddr structures that define the tunnel 317 endpoint addresses. In the case that transport mode is used, no 318 additional addresses are specified. The next payloads of the 319 message are the source and destination addresses of the 320 communication to be protected. In tunnel mode it is possible to 321 use address ranges instead of single address pairs to protect the 322 traffic of whole subnets with one SPD entry. It is also possible 323 to specify hard and soft lifetimes for policy entries, but these 324 payloads are optional. In the response from the kernel a hard, a 325 soft and a current lifetime are always present. The semantics are 326 the same as for SAD entries (see [1]). 328 SADB_X_SPDUPDATE: 330 If an existing SPD entry should be updated, the IKEv2 331 implementation sends a SADB_X_SPDUPDATE message to the kernel. 332 This massage has the following format: 334 336 The kernel responds with a message of the form: 338 340 The meaning of the payloads is the same as for the SADB_X_SPDADD 341 message. All the content of a SPD entry can be changed except the 342 sadb_x_policy_id field and the source/destination addresses, which 343 are the inner addresses in tunnel mode. However, the tunnel 344 endpoint addresses, which only exist in tunnel mode, can be 345 changed using a SADB_X_SPDUPDATE message. 347 SADB_X_SPDDELETE: 349 A SADB_X_SPDDELETE message is sent to the kernel in the case that 350 an existing SPD entry should be deleted. The entry is identified 351 by the policy data and the source and destination address. The 352 message has the following format: 354 356 The kernel responds with a message of the form: 358 360 If no corresponding entry can be found, the kernel returns a 361 message containing only the base header with the errno value set 362 appropriately. 364 SADB_X_SPDGET: 366 If the content of an existing SPD entry is needed, a SADB_X_SPDGET 367 message has to be sent to the kernel. The entry is identified by 368 the sadb_x_policy_id entry in the sadb_x_policy structure. This 369 id can obtained for example from a SADB_ACQUIRE message. The 370 format of a SADB_X_SPDGET message is: 372 374 The kernel responds with a message of the form: 376 378 If no entry has been found, the kernel returns an errno value in 379 the base header. 381 SADB_X_SPDDUMP: 383 If the kernel receives a SADB_X_SPDDUMP message, it prints out all 384 existing SPD entries on the console. The message format is: 386 388 SADB_X_SPDFLUSH: 390 To delete all SPD entries a SADB_X_SPDFLUSH message has to be sent 391 to the kernel. The format of the message is: 393 395 6. Algorithm Types 397 This document defines an IANA registry for the IKEv2 defined 398 cryptographic algorithms and thereby extends the algorithms defined 399 by PF_KEY (see Section 3.5 of [1]). The same set of algorithms is 400 available to MOBIKE. 402 The following algorithms have been defined already in PF_KEY, Section 403 3.5 of [1]): 405 /* Integrity (Authentication) Algorithms */ 407 PF_KEY Algorithm Name Value Description 408 ---------------------------+---------+----------------------- 409 SADB_AALG_NONE | 0 | not used 410 SADB_AALG_MD5HMAC | 2 | HMAC-MD5-96 411 SADB_AALG_SHA1HMAC | 3 | HMAC-SHA-1-96 413 /* Encryption Algorithms */ 415 PF_KEY Algorithm Name Value Description 416 ---------------------------+---------+----------------------- 417 SADB_EALG_NONE | 0 | not used 418 SADB_EALG_DESCBC | 2 | DES in CBC mode 419 SADB_EALG_3DESCBC | 3 | TripleDES in CBC mode 420 SADB_EALG_NULL | 11 | NULL encryption 422 The algorithm for SADB_AALG_MD5_HMAC is defined in [3]. The 423 algorithm for SADB_AALG_SHA1HMAC is defined in [4]. The algorithm 424 for SADB_EALG_DESCBC is defined in [5]. SADB_EALG_NULL is the NULL 425 encryption algorithm, defined in [6]. The SADB_EALG_NONE value is 426 not to be used in any security association except those which have no 427 possible encryption algorithm in them (e.g. IPsec AH). 429 This document enhances this list with the following algorithms: 431 /* Integrity (Authentication) Algorithms */ 433 PF_KEY Algorithm Name Value Description 434 ---------------------------+---------+----------------------- 435 SADB_AALG_AESXCBCMAC | 4 | AES-XCBC-MAC-96 436 SADB_X_AALG_SHA2_256HMAC | 5 | SHA2-HMAC-256 437 SADB_X_AALG_SHA2_384HMAC | 6 | SHA2-HMAC-384 438 SADB_X_AALG_SHA2_512HMAC | 7 | SHA2-HMAC-512 439 SADB_X_AALG_RIPEMD160HMAC | 8 | HMAC-RIPEMD-160-96 441 /* Encryption algorithms */ 443 PF_KEY Algorithm Name Value Description 444 ---------------------------+---------+----------------------- 445 SADB_EALG_AESCBC128 | 12 | AES with 446 | | 128-bit keys in CBC mode 447 SADB_X_EALG_CASTCBC | 6 | CAST in CBC mode 448 SADB_X_EALG_BLOWFISHCBC | 7 | BLOWFISH in CBC mode 449 SADB_X_EALG_AESCBC | 12 | AES in CBC mode 450 SADB_X_EALG_AESCTR | 13 | AES Counter Mode 452 AES-XCBC-MAC-96 is defined in [7] and AES with 128-bit keys in CBC 453 mode is defined in [8]. AES counter mode has been defined for usage 454 with IPsec ESP (see [9]). HMAC-RIPEMD-160-96 is defined in [10]. 456 Note that compression algorithms also need to be considered. This 457 document does not list them, however. 459 7. Traffic Selector Extensions 461 Information about Traffic Selectors should also be added to a updated 462 version of PF_KEY [1]. This is left for future work. 464 8. IANA Considerations 466 This document defines an IANA registry for the cryptographic 467 algorithms used within PF_KEY: 469 TBD 471 9. Security Considerations 473 This document describes an extension to PF_KEY [1] and therefore 474 inherits its security properties. Since this interface allows 475 existing entries in the security association database (and the 476 security policy database) to be created, updated or deleted it needs 477 to be ensured that only trusted and privileged processes are allowed 478 to this interface. 480 10. Acknowledgments 482 The authors would like to thank Bao G. Phan for his initial PF_KEY 483 implementation at US Naval Research Lab and the developers of FreeBSD 484 for providing their PF_KEY implementation and for extending it for 485 policy support, as well as R.J. Atkinson and Dan McDonald. 487 11. References 489 11.1 Normative References 491 [1] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management 492 API, Version 2", RFC 2367, July 1998. 494 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 495 Levels", March 1997. 497 [3] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and 498 AH", RFC 2403, November 1998. 500 [4] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 501 and AH", RFC 2404, November 1998. 503 [5] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm 504 With Explicit IV", RFC 2405, November 1998. 506 [6] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its 507 Use With IPsec", RFC 2410, November 1998. 509 [7] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and 510 Its Use With IPsec", RFC 3566, September 2003. 512 [8] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 513 Algorithm and Its Use with IPsec", RFC 3602, September 2003. 515 [9] Housley, R., "Using Advanced Encryption Standard (AES) Counter 516 Mode With IPsec Encapsulating Security Payload (ESP)", 517 RFC 3686, January 2004. 519 [10] Keromytis, A. and N. Provos, "The Use of HMAC-RIPEMD-160-96 520 within ESP and AH", RFC 2857, June 2000. 522 [11] Hoffman, P., "Cryptographic Suites for IPsec", 523 draft-ietf-ipsec-ui-suites-06 (work in progress), April 2004. 525 11.2 Informative References 527 [12] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", 528 draft-ietf-mobike-design-02 (work in progress), February 2005. 530 [13] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 531 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 533 [14] , ., "PF_KEY Extensions for IPsec Policy Management in KAME 534 Stack, available at http://www.kame.net/newsletter/20021210/ 535 (February 2005)", 12 2002. 537 Authors' Addresses 539 Udo Schilcher 540 Siemens AG 541 Otto-Hahn-Ring 6 542 Munich, Bayern 81739 543 Germany 545 Email: udo.schilcher@edu.uni-klu.ac.at 547 Hannes Tschofenig 548 Siemens AG 549 Otto-Hahn-Ring 6 550 Munich, Bayern 81739 551 Germany 553 Email: Hannes.Tschofenig@siemens.com 555 Franz Muenz 556 Siemens AG 557 Otto-Hahn-Ring 6 558 Munich, Bayern 81739 559 Germany 561 Email: Franz.Muenz@thirdwave.de 563 Intellectual Property Statement 565 The IETF takes no position regarding the validity or scope of any 566 Intellectual Property Rights or other rights that might be claimed to 567 pertain to the implementation or use of the technology described in 568 this document or the extent to which any license under such rights 569 might or might not be available; nor does it represent that it has 570 made any independent effort to identify any such rights. Information 571 on the procedures with respect to rights in RFC documents can be 572 found in BCP 78 and BCP 79. 574 Copies of IPR disclosures made to the IETF Secretariat and any 575 assurances of licenses to be made available, or the result of an 576 attempt made to obtain a general license or permission for the use of 577 such proprietary rights by implementers or users of this 578 specification can be obtained from the IETF on-line IPR repository at 579 http://www.ietf.org/ipr. 581 The IETF invites any interested party to bring to its attention any 582 copyrights, patents or patent applications, or other proprietary 583 rights that may cover technology that may be required to implement 584 this standard. Please address the information to the IETF at 585 ietf-ipr@ietf.org. 587 Disclaimer of Validity 589 This document and the information contained herein are provided on an 590 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 591 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 592 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 593 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 594 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 595 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 597 Copyright Statement 599 Copyright (C) The Internet Society (2005). This document is subject 600 to the rights, licenses and restrictions contained in BCP 78, and 601 except as set forth therein, the authors retain all their rights. 603 Acknowledgment 605 Funding for the RFC Editor function is currently provided by the 606 Internet Society.