1 2 3 4INTERNET-DRAFT D. Dukes 5Expires March 2002 R. Pereira 6Document: <draft-dukes-ike-mode-cfg-02.txt> Cisco Systems 7 September 2001 8 9 10 The ISAKMP Configuration Method 11 <draft-dukes-ike-mode-cfg-02.txt> 12 13 14 15Status of this Memo 16 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [1]. 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as "work in 27 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 32 33 34Abstract 35 36 This document describes a new ISAKMP method that allows 37 configuration items to be exchanged securely by using both 38 push/acknowledge or request/reply paradigms. 39 40 The authors currently intend this document to be published as an 41 Informational RFC, not a standards-track document, so that the many 42 IPsec implementations that have implemented to earlier drafts of 43 this protocol can have a single stable reference. 44 45 Comments regarding this draft should be sent to ietf-mode- 46 cfg@vpnc.org or to the authors. 47 48 49Conventions used in this document 50 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 53 this document are to be interpreted as described in RFC-2119 [2]. 54 55 56 57 58 59Dukes, Pereira 1 60 61 The ISAKMP Configuration Method September 2001 62 63 64 65Table of Contents 66 1. Introduction....................................................3 67 1.1. Changes since last revision...................................3 68 1.2. Reader Prerequisites..........................................3 69 2. Configuration Transaction.......................................3 70 3. Configuration Method Exchange and Payload.......................4 71 3.1. Transaction Exchanges.........................................4 72 3.1.1. Protected Exchanges.........................................4 73 3.1.2. Unprotected Exchanges.......................................5 74 3.2. Attribute Payload.............................................5 75 3.3. Configuration Message Types...................................6 76 3.4. Configuration Attributes......................................6 77 3.5. Retransmission................................................9 78 4. Exchange Positioning............................................9 79 5. Specific Uses...................................................9 80 5.1. Requesting an Internal Address................................9 81 5.2. Requesting the Peer�s Version................................10 82 6. Enterprise Management Considerations...........................11 83 7. Security Considerations........................................11 84 8. References.....................................................11 85 10. Author's Addresses............................................12 86 Full Copyright Statement..........................................13 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118Dukes, Pereira 2 119 120 The ISAKMP Configuration Method September 2001 121 122 123 1241. Introduction 125 126 The ISAKMP protocol provides a framework to negotiate and generate 127 Security Associations. While negotiating SAs, it is sometimes quite 128 useful to retrieve certain information from the other peer before 129 the non-ISAKMP SA can be established. Luckily, ISAKMP is also 130 flexible enough to provide configuration information and do it 131 securely. This document will present a mechanism to extend ISAKMP 132 to provide such functionality. 133 1341.1. Changes since last revision. 135 136 The last revision of this document was published as "draft-dukes- 137 ike-mode-cfg-01.txt", and was originally named "draft-ietf-ipsec- 138 isakmp-mode-cfg" 139 140 o Fixed some typo's and cross-references. 141 1421.2. Reader Prerequisites 143 144 It is assumed that the reader is familiar with the terms and 145 concepts described in the "Security Architecture for the Internet 146 Protocol" [ArchSec] and "IP Security Document Roadmap" [Thayer97] 147 documents. 148 149 Readers are advised to be familiar with both [IKE] and [ISAKMP] 150 because of the terminology used within this document and the fact 151 that this document is an extension of both of those documents. 152 153 1542. Configuration Transaction 155 156 A "Configuration Transaction" is defined as one or more transaction 157 exchanges each consisting of two messages, the first being either a 158 Set or a Request and the second being either an Acknowledge or a 159 Reply, respectively. A common identifier is used to identify the 160 configuration transaction between exchanges. 161 162 There are two paradigms to follow for this method. 163 164 o "Request/Reply" allows a host to request information from an 165 informed hosts (a configuration manager). If the attributes in the 166 Request message are not empty, then these attributes are taken as 167 suggestions for that attribute. The Reply message MAY wish to 168 choose those values, or return new values. It MAY also add new 169 attributes and not include some requested attributes. 170 171 A Reply MUST always be sent when a Request is received, even if it 172 is an empty Reply or if there are missing attributes in the Request. 173 This merely means that the requested attributes were not available 174 or unknown. 175 176 177Dukes, Pereira 3 178 179 The ISAKMP Configuration Method September 2001 180 181 182 Initiator Responder 183 --------------- -------------- 184 REQUEST --> 185 <-- REPLY 186 187 o "Set/Acknowledge" works on the push principle that allows a 188 configuration manager (a host that wishes to send information to 189 another host) to start the configuration transaction. This code 190 sends attributes that it wants the peer to alter. The Acknowledge 191 code MUST return the zero length attributes that it accepted. Those 192 attributes that it did not accept will NOT be sent back in the 193 acknowledgement. 194 195 Initiator Responder 196 --------------- ------------------- 197 SET --> 198 <-- ACKNOWLEDGE 199 200 Transaction exchanges are completed once the Reply or Acknowledge 201 code is received. If one is not received, the implementation MAY 202 wish to retransmit the original message as detailed in a later 203 section. 204 205 The initiator and responder are not necessarily the same as the 206 initiator and responder of the ISAKMP exchange. 207 208 2093. Configuration Method Exchange and Payload 210 2113.1. Transaction Exchanges 212 213 A new exchange mode is required for the configuration method. This 214 exchange is called the "Transaction Exchange" and has a value of 6. 215 This exchange is quite similar to the Information exchange described 216 in [ISAKMP] and [IKE], but allows for multi-exchange transactions 217 instead of being a one-way transmittal of information. 218 219 This specification protects ISAKMP Transaction Exchanges when 220 possible. 221 222 2233.1.1. Protected Exchanges 224 225 Once an ISAKMP security association has been established (and 226 SKEYID_e and SKEYID_a have been generated), the ISAKMP Transaction 227 Exchange is as follows: 228 229 Initiator Responder 230 ----------- ----------- 231 HDR*, HASH, ATTR --> 232 <-- HDR*, HASH, ATTR 233 234 235 236Dukes, Pereira 4 237 238 The ISAKMP Configuration Method September 2001 239 240 241 Where the HASH payload contains the prf output, using SKEYID_a as 242 the key, and the M-ID (ISAKMP header Message ID) unique to this 243 exchange concatenated with all of the payloads after the HASH 244 payload. In other words, the hash for the above exchange is: 245 246 HASH = prf( SKEYID_a, M-ID | ATTR ) 247 248 Multiple ATTR payloads MAY NOT be present in the Transaction 249 Exchange. 250 251 As noted, the message ID in the ISAKMP header-- as used in the prf 252 computation-- is unique to this transaction exchange and MUST NOT be 253 the same as the message ID of another transaction exchange. The 254 derivation of the initialization vector (IV) for the first message, 255 used with SKEYID_e to encrypt the message, is described in Appendix 256 B of [IKE]. Subsequent IVs are taken from the last ciphertext block 257 of the previous message as described in [IKE]. 258 259 2603.1.2. Unprotected Exchanges 261 262 If the ISAKMP security association has not yet been established at 263 the time of the Transaction Exchange and the information being 264 exchanged is not sensitive, the exchange MAY be done in the clear 265 without an accompanying HASH payload. 266 267 Initiator Responder 268 ----------- ----------- 269 HDR, ATTR --> 270 <-- HDR, ATTR 271 272 Multiple ATTR payloads MAY NOT be present in the Transaction 273 Exchange. 274 275 2763.2. Attribute Payload 277 278 A new payload is defined to carry attributes as well as the type of 279 transaction message. 280 281 1 2 3 282 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 ! Next Payload ! RESERVED ! Payload Length ! 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 ! Type ! RESERVED ! Identifier ! 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 ! ! 289 ~ Attributes ~ 290 ! ! 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 293 The Attributes Payload fields are defined as follows: 294 295Dukes, Pereira 5 296 297 The ISAKMP Configuration Method September 2001 298 299 300 301 o Next Payload (1 octet) - Identifier for the payload type of the 302 next payload in the message. If the current payload is the last in 303 the message, then this field will be 0. 304 305 o RESERVED (1 octet) - Unused, set to 0. 306 307 o Payload Length (2 octets) - Length in octets of the current 308 payload, including the generic payload header, the transaction- 309 specific header and all attributes. If the length does not match 310 the length of the payload headers plus the attributes, (i.e. an 311 attribute is half contained within this payload) then entire payload 312 MUST be discarded. 313 314 o Attribute Message Type (1 octet) - Specifies the type of message 315 represented by the attributes. These are defined in the next 316 section. 317 318 o RESERVED (1 octet) - Unused, set to 0. 319 320 o Identifier (2 octets) - An identifier used to reference a 321 configuration transaction within the individual messages. 322 323 o Attributes (variable length) - Zero or more ISAKMP Data Attributes 324 as defined in [ISAKMP]. The attribute types are defined in a later 325 section. 326 327 The payload type for the Attributes Payload is 14. 328 329 3303.3. Configuration Message Types 331 332 These values are to be used within the Type field of an Attribute 333 ISAKMP payload. 334 335 Types Value 336 ========================== =========== 337 RESERVED 0 338 ISAKMP_CFG_REQUEST 1 339 ISAKMP_CFG_REPLY 2 340 ISAKMP_CFG_SET 3 341 ISAKMP_CFG_ACK 4 342 Reserved for Future Use 5-127 343 Reserved for Private Use 128-255 344 345 Messages with unknown types SHOULD be silently discarded. 346 347 3483.4. Configuration Attributes 349 350 Zero or more ISAKMP attributes [ISAKMP] are contained within an 351 Attributes Payload. Zero length attribute values are usually sent in 352 a Request and MUST NOT be sent in a Response. 353 354Dukes, Pereira 6 355 356 The ISAKMP Configuration Method September 2001 357 358 359 360 All IPv6 specific attributes are mandatory only if the 361 implementation supports IPv6 and vice versa for IPv4. Mandatory 362 attributes are stated below. 363 364 Unknown private attributes SHOULD be silently discarded. 365 366 The following attributes are currently defined: 367 368 Attribute Value Type Length 369 ========================= ======= ========== ===================== 370 RESERVED 0 371 INTERNAL_IP4_ADDRESS 1 Variable 0 or 4 octets 372 INTERNAL_IP4_NETMASK 2 Variable 0 or 4 octets 373 INTERNAL_IP4_DNS 3 Variable 0 or 4 octets 374 INTERNAL_IP4_NBNS 4 Variable 0 or 4 octets 375 INTERNAL_ADDRESS_EXPIRY 5 Variable 0 or 4 octets 376 INTERNAL_IP4_DHCP 6 Variable 0 or 4 octets 377 APPLICATION_VERSION 7 Variable 0 or more 378 INTERNAL_IP6_ADDRESS 8 Variable 0 or 16 octets 379 INTERNAL_IP6_NETMASK 9 Variable 0 or 16 octets 380 INTERNAL_IP6_DNS 10 Variable 0 or 16 octets 381 INTERNAL_IP6_NBNS 11 Variable 0 or 16 octets 382 INTERNAL_IP6_DHCP 12 Variable 0 or 16 octets 383 INTERNAL_IP4_SUBNET 13 Variable 0 or 8 octets 384 SUPPORTED_ATTRIBUTES 14 Variable 0 or multiples of 2 385 INTERNAL_IP6_SUBNET 15 Variable 0 or 17 octets 386 Reserved for future use 16-16383 387 Reserved for private use 16384-32767 388 389 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - Specifies an address 390 within the internal network. This address is sometimes called a red 391 node address or a private address and MAY be a private address on 392 the Internet. Multiple internal addresses MAY be requested by 393 requesting multiple internal address attributes. The responder MAY 394 only send up to the number of addresses requested. 395 396 The requested address is valid until the expiry time defined with 397 the INTERNAL_ADDRESS EXPIRY attribute or until the ISAKMP SA that 398 was used to secure the request expires. The address MAY also expire 399 when the IPSec (phase 2) SA expires, if the request is associated 400 with a phase 2 negotiation. If no ISAKMP SA was used to secure the 401 request, then the response MUST include an 402 expiry or the host MUST expire the SA after an implementation- 403 defined time. 404 405 An implementation MUST support this attribute. 406 407 o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal 408 network's netmask. Only one netmask is allowed in the request and 409 reply messages (e.g. 255.255.255.0) and it MUST be used only with an 410 INTERNAL_ADDRESS attribute. 411 412 413Dukes, Pereira 7 414 415 The ISAKMP Configuration Method September 2001 416 417 418 An implementation MUST support this attribute. 419 420 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS 421 server within the network. Multiple DNS servers MAY be requested. 422 The responder MAY respond with zero or more DNS server attributes. 423 424 o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of a 425 NetBios Name Server (WINS) within the network. Multiple NBNS 426 servers MAY be requested. The responder MAY respond with zero or 427 more NBNS server attributes. 428 429 o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that the 430 host can use the internal IP address. The host MUST renew the IP 431 address before this expiry time. Only one attribute MAY be present 432 in the reply. 433 434 An implementation MUST support this attribute. 435 436 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send 437 any internal DHCP requests to the address contained within the 438 attribute. Multiple DHCP servers MAY be requested. The responder 439 MAY respond with zero or more DHCP server attributes. 440 441 o APPLICATION_VERSION - The version or application information of 442 the IPSec host. This is a string of printable ASCII characters that 443 is NOT null terminated. 444 445 This attribute does not need to be secured. 446 447 An implementation MUST support this attribute. 448 449 o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- 450 device protects. This attribute is made up of two fields; the first 451 being an IP address and the second being a netmask. Multiple sub- 452 networks MAY be requested. The responder MAY respond with zero or 453 more sub-network attributes. 454 455 An implementation MUST support this attribute. 456 457 o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute 458 must be zero length and specifies a query to the responder to reply 459 back with all of the attributes that it supports. The response 460 contains an attribute that contains a set of attribute identifiers 461 each in 2 octets. The length divided by 2 (bytes) would state the 462 number of supported attributes contained in the response. 463 464 An implementation MUST support this attribute. 465 466 o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- 467 device protects. This attribute is made up of two fields; the first 468 being a 16 octet IPv6 address the second being a one octet prefix- 469 mask as defined in [ADDRIPV6]. Multiple sub-networks MAY be 470 471 472Dukes, Pereira 8 473 474 The ISAKMP Configuration Method September 2001 475 476 477 requested. The responder MAY respond with zero or more sub-network 478 attributes. 479 480 An implementation MUST support this attribute. 481 482 Note that no recommendations are made in this document how an 483 implementation actually figures out what information to send in a 484 reply. i.e. we do not recommend any specific method of (an edge 485 device) determining which DNS server should be returned to a 486 requesting host. 487 488 4893.5. Retransmission 490 491 Retransmission SHOULD follow the same retransmission rules used with 492 standard ISAKMP messages. 493 494 4954. Exchange Positioning 496 497 The exchange and messages defined within this document MAY appear at 498 any time. Because of security considerations with most attributes, 499 the exchange SHOULD be secured with an ISAKMP phase 1 SA. 500 501 Depending on the type of transaction and the information being 502 exchanged, the exchange MAY be dependant on an ISAKMP phase 1 SA 503 negotiation, a phase 2 SA negotiation, or none of the above. 504 505 The next section details specific functions and their position 506 within an ISAKMP negotiation. 507 508 5095. Specific Uses 510 511 The following descriptions detail how to perform specific functions 512 using this protocol. Other functions are possible and thus this 513 list is not a complete list of all of the possibilities. While 514 other functions are possible, the functions listed below MUST be 515 performed as detailed in this document to preserve interoperability 516 among different vendor's implementations. 517 518 5195.1. Requesting an Internal Address 520 521 This function provides address allocation to a remote host trying to 522 tunnel into a network protected by an edge device. The remote host 523 requests an address and optionally other information concerning the 524 internal network from the edge device. The edge device procures an 525 internal address for the remote host from any number of sources such 526 as a DHCP/BOOTP server or its own address pool. 527 528 Initiator Responder 529 ----------------------------- ------------------------------- 530 531Dukes, Pereira 9 532 533 The ISAKMP Configuration Method September 2001 534 535 536 HDR*, HASH, ATTR1(REQUEST) --> 537 <-- HDR*, HASH, ATTR2(REPLY) 538 ATTR1(REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 539 (either IPv4 or IPv6) but MAY also contain any number of additional 540 attributes that it wants returned in the response. 541 542 For example: 543 ATTR1(REQUEST) = 544 INTERNAL_ADDRESS(0.0.0.0) 545 INTERNAL_NETMASK(0.0.0.0) 546 INTERNAL_DNS(0.0.0.0) 547 548 ATTR2(REPLY) = 549 INTERNAL_ADDRESS(192.168.219.202) 550 INTERNAL_NETMASK(255.255.255.0) 551 INTERNAL_SUBNET(291.168.219.0/255.255.255.0) 552 553 All returned values will be implementation dependent. As can be 554 seen in the above example, the edge device MAY also send other 555 attributes that were not included in the REQUEST and MAY ignore the 556 non-mandatory attributes that it does not support. 557 558 This Transaction Exchange MUST occur after an ISAKMP phase 1 SA is 559 already established and before an ISAKMP phase 2 negotiation has 560 started, since that negotiation requires the internal address. 561 562 Initial Negotiation: 563 MainMode or AggressiveMode 564 TransactionMode (IP Address request) 565 QuickMode(s) 566 567 Subsequent address requests would be done without the phase 1 568 negotiation when there already exists a phase 1 SA. 569 570 Subsequent Negotiations: 571 TransactionMode (IP Address request) 572 QuickMode(s) 573 5745.2. Requesting the Peer's Version 575 576 An IPSec host wishing to inquire about the other peer's version 577 information (with or without security) MUST use this method. 578 579 Initiator Responder 580 ----------------------------- -------------------------- 581 HDR, ATTR1(REQUEST) --> 582 <-- HDR, ATTR2(REPLY) 583 584 ATTR1(REQUEST) = 585 APPLICATION_VERSION("") 586 587 ATTR2(REPLY) = 588 APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") 589 590Dukes, Pereira 10 591 592 The ISAKMP Configuration Method September 2001 593 594 595 596 The return text string will be implementation dependent. This 597 transaction MAY be done at any time and with or without any other 598 ISAKMP exchange and because the version information MAY be deemed 599 not sensitive, security is optional. 600 601 6026. Enterprise Management Considerations 603 604 The method defined in this document SHOULD NOT be used for wide 605 scale management. Its main intent is to provide a bootstrap 606 mechanism to exchange information within IPSec. While it MAY be 607 useful to use such a method of exchange information to some outlying 608 IPSec hosts or small networks, existing management protocols such as 609 DHCP [DHCP], RADIUS [RADIUS], SNMP or LDAP [LDAP] should be 610 considered for enterprise management as well as subsequent 611 information exchanges. 612 613 6147. Security Considerations 615 616 This entire draft discusses a new ISAKMP configuration method to 617 allow IPSec-enabled entities to acquire and share configuration 618 information. 619 620 The draft mandates that this exchange should normally occur after 621 the Phase I Security Association has been set up and that the entire 622 exchange be protected by that Phase I SA. Thus the exchange is as 623 secure as any Phase II SA negotiation. 624 625 This exchange MAY be secured (encrypted and authenticated) by other 626 means as well, such as pre-configured ESP [ESP] or data-link 627 security. 628 629 6308. References 631 632 633 [1] Bradner, S., "The Internet Standards Process -- Revision 634 3", BCP 9, RFC 2026, October 1996. 635 636 [2] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, March 1997 638 639 [Thayer97] R. Thayer, N. Doraswamy, R. Glenn. "IP Security Document 640 Roadmap", RFC2411 641 642 [ArchSec] S. Kent, R. Atkinson, "Security Architecture for the 643 Internet Protocol", RFC2401 644 645 [ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner, 646 "Internet Security Association and Key Management 647 Protocol", RFC2408 648 649Dukes, Pereira 11 650 651 The ISAKMP Configuration Method September 2001 652 653 654 655 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange 656 (IKE)", RFC2409 657 658 [DHCP] R. Droms, "Dynamic Host Configuration Protocol", 659 RFC2131 660 661 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 662 Authentication Dial In User Service (RADIUS)", RFC2138 663 664 [LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory 665 Access Protocol (v3)", RFC2251 666 667 [ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", 668 RFC2406 669 670 [ADDRIPV6] Hinden, R., "IP Version 6 Addressing Architecture", 671 RFC 2373, July 1998. 672 673 6749. Acknowledgments 675 676 The editors would like to thank Sanjay Anand, Baiju V. Patel, 677 Stephane Beaulieu, Tim Jenkins, Peter Ford, Bob Moskowitz and Shawn 678 Mamros. 679 680 68110. Author's Addresses 682 683 Darren Dukes 684 Cisco Systems Co. 685 365 March Road 686 Kanata, ON, Canada 687 Phone: 1-613-271-3679 688 Email: ddukes@cisco.com 689 690 Roy Pereira 691 Cisco Systems, Inc. 692 170 Tasman Drive 693 San Jose, CA, USA 694 Phone: 1-408-526-6793 695 Email: royp@cisco.com 696 697 698 699 700 701 702 703 704 705 706 707 708Dukes, Pereira 12 709 710 The ISAKMP Configuration Method September 2001 711 712 713 714Full Copyright Statement 715 716 "Copyright (C) The Internet Society (date). All Rights Reserved. 717 This document and translations of it may be copied and furnished to 718 others, and derivative works that comment on or otherwise explain it 719 or assist in its implementation may be prepared, copied, published 720 and distributed, in whole or in part, without restriction of any 721 kind, provided that the above copyright notice and this paragraph 722 are included on all such copies and derivative works. However, this 723 document itself may not be modified in any way, such as by removing 724 the copyright notice or references to the Internet Society or other 725 Internet organizations, except as needed for the purpose of 726 developing Internet standards in which case the procedures for 727 copyrights defined in the Internet Standards process must be 728 followed, or as required to translate it into 729 730 731 This Internet Draft expires September 2001 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767Dukes, Pereira 13 768 769 770