1 2 3 4KERBEROS WORKING GROUP Johansson 5Internet-Draft Stockholm university 6Intended status: Standards Track November 3, 2008 7Expires: May 7, 2009 8 9 10 An information model for Kerberos version 5 11 draft-ietf-krb-wg-kdc-model-03 12 13Status of this Memo 14 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 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. 24 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 29 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 32 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 35 36 This Internet-Draft will expire on May 7, 2009. 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55Johansson Expires May 7, 2009 [Page 1] 56 57Internet-Draft KDC Information Model November 2008 58 59 60Abstract 61 62 This document describes an information model for Kerberos version 5 63 from the point of view of an administrative service. There is no 64 standard for administrating a kerberos 5 KDC. This document 65 describes the services exposed by an administrative interface to a 66 KDC. 67 68 69Table of Contents 70 71 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. How to interpret RFC2119 terms . . . . . . . . . . . . . . . . 5 74 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 75 5. Information model demarcation . . . . . . . . . . . . . . . . 7 76 6. Information model specification . . . . . . . . . . . . . . . 8 77 6.1. Principal . . . . . . . . . . . . . . . . . . . . . . . . 8 78 6.1.1. Principal: Attributes . . . . . . . . . . . . . . . . 8 79 6.1.2. Principal: Associations . . . . . . . . . . . . . . . 9 80 6.1.3. Principal: Remarks . . . . . . . . . . . . . . . . . . 10 81 6.2. KeySet . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 6.2.1. KeySet: Attributes . . . . . . . . . . . . . . . . . . 10 83 6.2.2. KeySet: Associations . . . . . . . . . . . . . . . . . 10 84 6.2.3. KeySet: Remarks . . . . . . . . . . . . . . . . . . . 10 85 6.3. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 6.3.1. Key: Attributes . . . . . . . . . . . . . . . . . . . 11 87 6.3.2. Key: Associations . . . . . . . . . . . . . . . . . . 12 88 6.3.3. Key: Remarks . . . . . . . . . . . . . . . . . . . . . 12 89 6.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 6.4.1. Policy: Attributes . . . . . . . . . . . . . . . . . . 12 91 6.4.2. Mandatory-to-implement Policy . . . . . . . . . . . . 13 92 7. Implementation Scenarios . . . . . . . . . . . . . . . . . . . 14 93 7.1. LDAP backend to KDC . . . . . . . . . . . . . . . . . . . 14 94 7.2. LDAP frontend to KDC . . . . . . . . . . . . . . . . . . . 14 95 7.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 102 Intellectual Property and Copyright Statements . . . . . . . . . . 19 103 104 105 106 107 108 109 110 111Johansson Expires May 7, 2009 [Page 2] 112 113Internet-Draft KDC Information Model November 2008 114 115 1161. Requirements notation 117 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167Johansson Expires May 7, 2009 [Page 3] 168 169Internet-Draft KDC Information Model November 2008 170 171 1722. Introduction 173 174 The Kerberos version 5 authentication service described in [RFC4120] 175 describes how a Key Distribution Service (KDC) provides 176 authentication to clients. The standard does not stipulate how a KDC 177 is managed and several "kadmin" servers have evolved. This document 178 describes the services required to administrate a KDC and the 179 underlying information model assumed by a kadmin-type service. 180 181 The information model is written in terms of "attributes" and 182 "services" or "interfaces" but the use of these particular words MUST 183 NOT be taken to imply any particular modeling paradigm so that 184 neither an object oriented model or an LDAP schema is intended. The 185 author has attempted to describe in natural language the intended 186 semantics and syntax of the components of the model. An LDAP schema 187 (for instance) based on this model will be more precise in the 188 expression of the syntax while preserving the semantics of this 189 model. 190 191 Implementations of this document MAY decide to change the names used 192 (eg principalName). If so an implementation MUST provide a name to 193 name mapping to this document. 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223Johansson Expires May 7, 2009 [Page 4] 224 225Internet-Draft KDC Information Model November 2008 226 227 2283. How to interpret RFC2119 terms 229 230 This document describes an information model for kerberos 5 but does 231 not directly describe any mapping onto a particular schema- or 232 modelling language. Hence an implementation of this model consists 233 of a mapping to such a language - eg an LDAP or SQL schema. The 234 precise interpretation of terms from [RFC2119] therefore require some 235 extra explanation. The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL 236 NOT mean that an implementation MUST provide a feature but does not 237 mean that this feature MUST be REQUIRED by the implementation - eg an 238 attribute is available in an LDAP schema but marked as OPTIONAL. If 239 a feature must be implemented and REQUIRED this is made explicit in 240 this model. The term MAY, OPTIONAL and RECOMMENDED means that an 241 implementation MAY need to REQUIRE the feature due to the particular 242 nature of the schema/modelling language. In some cases this is 243 expressly forbidden by this model (feature X MUST NOT be REQUIRED by 244 an implementation). 245 246 Note that any implementation of this model SHOULD be published as an 247 RFC. 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279Johansson Expires May 7, 2009 [Page 5] 280 281Internet-Draft KDC Information Model November 2008 282 283 2844. Acknowledgments 285 286 Love Hoernquist-Aestrand <lha@it.su.se> for important contributions. 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335Johansson Expires May 7, 2009 [Page 6] 336 337Internet-Draft KDC Information Model November 2008 338 339 3405. Information model demarcation 341 342 The information model specified in the next chapter describes 343 objects, properties of those objects and relations between those 344 objects. These elements comprise an abstract view of the data 345 represented in a KDC. It is important to understand that the 346 information model is not a schema. In particular the way objects are 347 compared for equality beyond that which is implied by the 348 specification of a syntax is not part of this specification. Nor is 349 ordering specified between elements of a particular syntax. 350 351 Further work on Kerberos will undoubtedly prompt updates to this 352 information model to reflect changes in the functions performed by 353 the KDC. Such extensions to the information model MUST always use a 354 normative reference to the relevant RFCs detailing the change in KDC 355 function. 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391Johansson Expires May 7, 2009 [Page 7] 392 393Internet-Draft KDC Information Model November 2008 394 395 3966. Information model specification 397 3986.1. Principal 399 400 The fundamental entity stored in a KDC is the principal. The 401 principal is associated to keys and generalizes the "user" concept. 402 The principal MUST be implemented in full and MUST NOT be optional in 403 an implementation 404 4056.1.1. Principal: Attributes 406 4076.1.1.1. principalName 408 409 The principalName MUST uniquely identify the principal within the 410 administrative context of the KDC. The type of the principalName is 411 not described in this document. It is a unique identifier and can be 412 viewed as an opaque byte string which can be compared for equality. 413 The attribute SHOULD be single valued. If an implementation supports 414 multiple values it MUST treat one of the values as special and allow 415 it to be fetched as if it was a single value. 416 4176.1.1.2. principalNotUsedBefore 418 419 The principal may not be used before this date. The syntax of the 420 attribute MUST be semantically equivalent with the standard ISO date 421 format. The attribute MUST be single valued. 422 4236.1.1.3. principalNotUsedAfter 424 425 The principal may not be used after this date. The syntax of the 426 attribute MUST be semantically equivalent with the standard ISO date 427 format. The attribute MUST be single valued. 428 4296.1.1.4. principalIsDisabled 430 431 A boolean attribute used to (temporarily) disable a principal. The 432 attribute MUST default to false. 433 4346.1.1.5. principalAliases 435 436 This multivalued attribute contains an unordered set of aliases for 437 the principal. Each alias SHOULD be unique within the administrative 438 domain represented by the KDC. The syntax of an alias is an opaque 439 identifier which can be compared for equality. 440 441 442 443 444 445 446 447Johansson Expires May 7, 2009 [Page 8] 448 449Internet-Draft KDC Information Model November 2008 450 451 4526.1.1.6. principalNumberOfFailedAuthenticationAttempts 453 454 This single valued integer attribute contains a count of the number 455 of times an authentication attempt was unsuccessful for this 456 principal. Implementations SHOULD NOT allow this counter to be 457 reset. 458 4596.1.1.7. principalLastFailedAuthentication 460 461 This single valued attribute contains the time and date for the last 462 failed authentication attempt for this principal. 463 4646.1.1.8. principalLastSuccessfulAuthentication 465 466 This single valued attribute contains the time and date for the last 467 successful authentication attempt for this principal. 468 4696.1.1.9. principalLastCredentialChange 470 471 This single valued attribute contains the time and date for the last 472 successful change of credential (eg password) this principal. 473 4746.1.1.10. principalCreateTime 475 476 This single valued attribute contains the time and date when this 477 principal was created 478 4796.1.1.11. principalModdifyTime 480 481 This single valued attribute contains the time and date when this 482 principal was modified excluding credentials change. 483 4846.1.1.12. principalMaximumTicketLifetime 485 486 This single valued attribute contains the delta time in seconds 487 representing the maximum ticket lifetime for tickets issued for this 488 principal. 489 4906.1.1.13. principalMaximumRenewableTicketLifetime 491 492 This single valued attribute contains the delta time in seconds 493 representing the maximum amount of time a ticket may be renewed for. 494 4956.1.2. Principal: Associations 496 497 Each principal MAY be associated with 1 or more KeySet and MAY be 498 associated with 1 or more Policies. The KeySet is represented as an 499 object in this model since it has attributes associated with it (the 500 501 502 503Johansson Expires May 7, 2009 [Page 9] 504 505Internet-Draft KDC Information Model November 2008 506 507 508 key version number). In typical situations the principal is 509 associated with exactly 1 KeySet but implementations MUST NOT assume 510 this case, i.e an implemenation of this standard (e.g an LDAP schema) 511 MUST be able to handle the general case of multiple KeySet associated 512 with each principal. 513 5146.1.3. Principal: Remarks 515 516 Traditionally a principal consists of a local-part and a realm 517 denoted in string form by local-part@REALM. The realm concept is 518 used to provide administrative boundaries and together with cross- 519 realm authentication provides scalability to Kerberos 5. However the 520 realm is not central to an administrative information model. For 521 instance the initialization or creation of a realm is equivalent to 522 creating a specific set of principals (krbtgt@REALM, etc) which is 523 covered by the model and services described in this document. A 524 realm is typically associated with policy covering (for instance) 525 keying and password management. The management of such policy and 526 their association to realms is beyond the scope of this document. 527 5286.2. KeySet 529 530 A KeySet is a set of keys associated with exactly one principal. 531 This object and its associations MUST NOT be REQUIRED by an 532 implementation. It is expected that most implementations of this 533 standard will use the set/change password protocol for all aspects of 534 key management [I-D.ietf-krb-wg-kerberos-set-passwd]. This 535 information model only includes these objects for the sake of 536 completenes. 537 5386.2.1. KeySet: Attributes 539 5406.2.1.1. keySetVersionNumber 541 542 This is traditionally called the key version number (kvno). This is 543 a single valued attribute containing a positive integer. 544 5456.2.2. KeySet: Associations 546 547 To each KeySet MUST be associated a set of 1 or more Keys. 548 5496.2.3. KeySet: Remarks 550 551 The reason for separating the KeySet from the Principal is security. 552 The security of Kerberos 5 depends absolutely on the security of the 553 keys stored in the KDC. The KeySet type is provided to make this 554 clear and to make separation of keys from other parts of the model 555 clear. 556 557 558 559Johansson Expires May 7, 2009 [Page 10] 560 561Internet-Draft KDC Information Model November 2008 562 563 564 Implementations of this standard (eg an LDAP schema) MUST make a 565 clear separation between the representation of KeySet from other 566 information objects. 567 5686.3. Key 569 570 Implementations of this model MUST NOT REQUIRE keys to be 571 represented. 572 5736.3.1. Key: Attributes 574 5756.3.1.1. keyEncryptionType 576 577 The enctype SHOULD be represented as an enumeration of the enctypes 578 supported by the KDC. 579 5806.3.1.2. keyValue 581 582 The binary representation of the key data. This MUST be a single 583 valued octet string. 584 5856.3.1.3. keySaltValue 586 587 The binary representation of the key salt. This MUST be a single 588 valued octet string. 589 5906.3.1.4. keyStringToKeyParameter 591 592 This MUST be a single valued octet string representing an opaque 593 parameter associated with the enctype. 594 5956.3.1.5. keyNotUsedAfter 596 597 This key MUST NOT be used after this date. The syntax of the 598 attribute MUST be semantically equivalent with the standard ISO date 599 format. This MUST be a single-valued attribute. 600 6016.3.1.6. keyNotUsedBefore 602 603 This key MUST NOT be used before this date. The syntax of the 604 attribute MUST be semantically equivalent with the standard ISO date 605 format. This MUST be a single-valued attribute. 606 6076.3.1.7. keyIsDisabled 608 609 This is a boolean attribute which must be set to false by default. 610 If this attribute is true the key MUST NOT be used. This is used to 611 temporarily disable a key. 612 613 614 615Johansson Expires May 7, 2009 [Page 11] 616 617Internet-Draft KDC Information Model November 2008 618 619 6206.3.2. Key: Associations 621 622 None 623 6246.3.3. Key: Remarks 625 626 The security of the keys is an absolute requirement for the operation 627 of Kerberos 5. If keys are implemented adequate protection from 628 unauthorized modification and disclosure MUST be available and 629 REQUIRED by the implementation. 630 6316.4. Policy 632 633 Implementations SHOULD implement policy but MAY allow them to be 634 OPTIONAL. The Policy should be thought of as a 'typed hole'. i.e an 635 opaque binary value paired with an identifier of type of data 636 contained in the binary value. Both attributes (type and value) must 637 be present. 638 6396.4.1. Policy: Attributes 640 6416.4.1.1. policyIdentifier 642 643 The policyIdentifier MUST be unique within the local administrative 644 context and MUST be globally unique. Possible types of identifiers 645 include: 646 647 An Object Identifier (OID) 648 649 A URN 650 651 A UUID 652 653 The use of OIDs is recommended for this purpose. 654 6556.4.1.2. policyIsCritical 656 657 This boolean attribute indicates that the KDC MUST be able to 658 correctly interpret and apply this policy for the key to be used. 659 6606.4.1.3. policyContent 661 662 This is an optional single opaque binary value used to store a 663 representation of the policy. In general a policy cannot be fully 664 expressed using attribute-value pairs. The policyContent is OPTIONAL 665 in the sense that an implementation MAY use it to store an opaque 666 value for those policy-types which are not directly representable in 667 that implementation. 668 669 670 671Johansson Expires May 7, 2009 [Page 12] 672 673Internet-Draft KDC Information Model November 2008 674 675 6766.4.1.4. policyUse 677 678 This is an optional single enumerated string value used to describe 679 the applicability of the policy. Implementations SHOULD provide this 680 attribute and MUST (if the attribute is implemented) describe the 681 enumerated set of possible values. 682 6836.4.2. Mandatory-to-implement Policy 684 685 All implementations MUST be able to represent the policies listed in 686 this section. Implementations are not required to use the same 687 underlying data-representation for the policyContent binary value but 688 SHOULD use the same OIDs as the policyIdentifier. 689 6906.4.2.1. Password Quality Policy 691 692 Password quality policy controls the requirements placed by the KDC 693 on new passwords. This policy SHOULD be identified by the OID <TBD>. 694 6956.4.2.2. Password Management Policy 696 697 Password management policy controls how passwords are changed. This 698 policy SHOULD be identified by the OID <TBD>. 699 7006.4.2.3. Keying Policy 701 702 A keying policy specifies the association of enctypes with new 703 principals, i.e when a principal is created one of the possibly many 704 applicable keying policies determine the set of keys to associate 705 with the principal. In general the expression of a keying policy may 706 require a Turing-complete language. This policy SHOULD be identified 707 by the OID <TBD>. 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727Johansson Expires May 7, 2009 [Page 13] 728 729Internet-Draft KDC Information Model November 2008 730 731 7327. Implementation Scenarios 733 734 There are several ways to implement an administrative service for 735 Kerberos 5 based on this information model. In this section we list 736 a few of them. 737 7387.1. LDAP backend to KDC 739 740 Given an LDAP schema implementation of this information model it 741 would be possible to build an administrative service by backending 742 the KDC to a directory server where principals and keys are stored. 743 Using the security mechanisms available on the directory server keys 744 are protected from access by anyone apart from the KDC. 745 Administration of the principals, policy and other non-key data is 746 done through the directory server while the keys are modified using 747 the set/change password protocol 748 [I-D.ietf-krb-wg-kerberos-set-passwd]. 749 7507.2. LDAP frontend to KDC 751 752 An alternative way to provide a directory interface to the KDC is to 753 implement an LDAP-frontend to the KDC which exposes all non-key 754 objects as entries and attributes. As in the example above all keys 755 are modified using the set/change password protocol 756 [I-D.ietf-krb-wg-kerberos-set-passwd]. In this scenario the 757 implementation would typically not use a traditional LDAP 758 implementation but treat LDAP as an access-protocol to data in the 759 native KDC database. 760 7617.3. SOAP 762 763 Given an XML schema implementation of this information model it would 764 be possible to build a SOAP-interface to the KDC. This demonstrates 765 the value of creating an abstract information model which is mappable 766 to multiple schema representations. 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783Johansson Expires May 7, 2009 [Page 14] 784 785Internet-Draft KDC Information Model November 2008 786 787 7888. Security Considerations 789 790 This document describes an abstract information model for Kerberos 5. 791 The Kerberos 5 protocol depends on the security of the keys stored in 792 the KDC. The model described here assumes that keys MUST NOT be 793 transported in the clear over the network and furthermore that keys 794 are treated as write-only attributes that SHALL only be modified 795 (using the administrative interface) by the change-password protocol 796 [I-D.ietf-krb-wg-kerberos-set-passwd]. 797 798 Exposing the object model of a KDC typically implies that objects can 799 be modified and/or deleted. In a KDC not all principals are created 800 equal, so that for instance deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM 801 effectively disables the EXAMPLE.COM realm. Hence access control is 802 paramount to the security of any implementation. This document does 803 not (at the time of writing - leifj) mandate access control. This 804 only implies that access control is beyond the scope of the standard 805 information model, i.e that access control may not be accessible via 806 any protocol based on this model. If access control objects is 807 exposed via an extension to this model the presence of access control 808 may in itself provide points of attack by giving away information 809 about principals with elevated rights etc. etc. 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839Johansson Expires May 7, 2009 [Page 15] 840 841Internet-Draft KDC Information Model November 2008 842 843 8449. IANA Considerations 845 846 None 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895Johansson Expires May 7, 2009 [Page 16] 896 897Internet-Draft KDC Information Model November 2008 898 899 90010. References 901 90210.1. Normative References 903 904 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 905 Requirement Levels", BCP 14, RFC 2119, March 1997. 906 907 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 908 Kerberos Network Authentication Service (V5)", RFC 4120, 909 July 2005. 910 91110.2. Informative References 912 913 [I-D.ietf-krb-wg-kerberos-set-passwd] 914 Williams, N., "Kerberos Set/Change Key/Password Protocol 915 Version 2", draft-ietf-krb-wg-kerberos-set-passwd-07 (work 916 in progress), September 2007. 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951Johansson Expires May 7, 2009 [Page 17] 952 953Internet-Draft KDC Information Model November 2008 954 955 956Author's Address 957 958 Leif Johansson 959 Stockholm university 960 Avdelningen foer IT och Media 961 Stockholm SE-106 91 962 963 Email: leifj@it.su.se 964 URI: http://people.su.se/~leifj/ 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007Johansson Expires May 7, 2009 [Page 18] 1008 1009Internet-Draft KDC Information Model November 2008 1010 1011 1012Full Copyright Statement 1013 1014 Copyright (C) The IETF Trust (2008). 1015 1016 This document is subject to the rights, licenses and restrictions 1017 contained in BCP 78, and except as set forth therein, the authors 1018 retain all their rights. 1019 1020 This document and the information contained herein are provided on an 1021 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1022 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1023 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1024 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1025 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1026 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1027 1028 1029Intellectual Property 1030 1031 The IETF takes no position regarding the validity or scope of any 1032 Intellectual Property Rights or other rights that might be claimed to 1033 pertain to the implementation or use of the technology described in 1034 this document or the extent to which any license under such rights 1035 might or might not be available; nor does it represent that it has 1036 made any independent effort to identify any such rights. Information 1037 on the procedures with respect to rights in RFC documents can be 1038 found in BCP 78 and BCP 79. 1039 1040 Copies of IPR disclosures made to the IETF Secretariat and any 1041 assurances of licenses to be made available, or the result of an 1042 attempt made to obtain a general license or permission for the use of 1043 such proprietary rights by implementers or users of this 1044 specification can be obtained from the IETF on-line IPR repository at 1045 http://www.ietf.org/ipr. 1046 1047 The IETF invites any interested party to bring to its attention any 1048 copyrights, patents or patent applications, or other proprietary 1049 rights that may cover technology that may be required to implement 1050 this standard. Please address the information to the IETF at 1051 ietf-ipr@ietf.org. 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063Johansson Expires May 7, 2009 [Page 19] 1064 1065