idnits 2.17.1 draft-calhoun-diameter-proxy-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [8]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 931 has weird spacing: '...ize per packe...' == Line 1042 has weird spacing: '... copied and ...' == Line 1043 has weird spacing: '...s, and deriv...' == Line 1045 has weird spacing: '...blished and d...' == Line 1046 has weird spacing: '...hat the above...' == (6 more instances...) == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that unless noted, the 'P' bit can be set on any DIAMETER AVP. The Proxy-State AVP MUST not have the 'P' bit set since this AVP will be removed at each hop. Any other AVP that have similar properties (e.g. it will be removed or modified at each hop) MUST NOT have the 'P' bit enabled. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '1' is defined on line 975, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 978, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 980, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 983, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 985, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 987, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 993, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-08 -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '5') -- No information found for draft-calhoun-diameter-authen - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2486 (ref. '7') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '8') -- Unexpected draft version: The latest known version of draft-hoffman-pkcs-rsa-encrypt is -02, but you're referring to -03. (However, the state information for draft-calhoun-diameter-authen is not up-to-date. The last update was unsuccessful) ** Downref: Normative reference to an Informational draft: draft-hoffman-pkcs-rsa-encrypt (ref. '9') == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-02 -- Possible downref: Normative reference to a draft: ref. '10' ** Downref: Normative reference to an Informational RFC: RFC 2607 (ref. '11') ** Obsolete normative reference: RFC 2459 (ref. '12') (Obsoleted by RFC 3280) Summary: 16 errors (**), 0 flaws (~~), 20 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Standards Track Sun Microsystems, Inc. 3 Title: draft-calhoun-diameter-proxy-02.txt William Bulley 4 Date: August 1999 Merit Network, Inc. 6 DIAMETER 7 End-to-End Security/Referral Extensions 9 Status of this Memo 11 This document is an individual contribution for consideration by the 12 AAA Working Group of the Internet Engineering Task Force. Comments 13 should be submitted to the diameter@ipass.com mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-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: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The DIAMETER base protocol [2] allows for secure communication 39 between two DIAMETER nodes, and introduces the concept of proxying 40 through the Proxy-State AVP. However, the base protocol only allows 41 for hop-by-hop security, and the work done in the ROAMOPS WG [8] 42 shows that support for end-to-end security through proxies. This 43 document describes the extensions necessary to provide for secure 44 communication through DIAMETER proxies. 46 Table of Contents 48 1.0 Introduction 49 1.1 Copyright Statement 50 1.2 Requirements language 51 1.3 Changes in version -02 52 2.0 Extended AVP Format 53 3.0 Command Codes 54 3.1 Domain-Discovery-Request (DDR) 55 3.2 Domain-Discovery-Answer (DDA) 56 4.0 DIAMETER AVPs 57 4.1 Digital-Signature 58 4.2 X509-Certificate 59 4.3 X509-Certificate-URL 60 4.4 Next-Hop 61 5.0 Protocol Definition 62 5.1 Feature Advertisement/Discovery 63 5.2 DIAMETER Secure Proxying 64 5.3 Domain Discovery 65 5.4 Data Integrity 66 5.4.1 Using Digital Signatures 67 5.4.1 Using Mixed Data Integrity AVPs 68 5.5 AVP Data Encryption 69 5.5.1 AVP Encryption with Public Keys 70 5.6 Public Key Cryptography Support 71 5.6.1 X509-Certificate 72 5.6.2 X509-Certificate-URL 73 5.6.3 Static Public Key Configuration 74 6.0 IANA Considerations 75 7.0 References 76 8.0 Acknowledgements 77 9.0 Author's Address 78 10.0 Full Copyright Statement 80 1.0 Introduction 82 Many services, including ROAMOPS and MobileIP, have a requirement for 83 DIAMETER Server to proxy a request to another DIAMETER Server. The 84 concept of proxying AAA requests was introduced by RADIUS and has 85 been in use for many years. 87 The DIAMETER base protocol [2] does provide the basic capability for 88 proxying, but only defines hop-by-hop security, which has some known 89 security flaws. Specifically a fraudulent proxy server can modify 90 some portions of an AAA request in order to make the next hop 91 improperly believe that some services were rendered. For example, a 92 DIAMETER Proxy Server could modify an accounting request, such as the 93 number of bytes that a user transfered, and the end system would have 94 no way of determining that this change occured. 96 This specification contains the extensions necessary to DIAMETER to 97 allow for end-to-end message integrity and privacy. The document also 98 describes a method that DIAMETER can provide referal services to 99 clients. 101 The Extension number for this draft is two (2). This value is used in 102 the Extension-Id AVP as defined in [2]. 104 1.1 Copyright Statement 106 Copyright (C) The Internet Society 1999. All Rights Reserved. 108 1.2 Requirements language 110 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 111 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 112 described in [13]. 114 1.3 Changes in version -02 116 The following changes were made in version 02 of the document: 118 - New title 120 - A good cleanup of the abstract and the introduction. 122 - Fixed up text in section 4.2 that stated that all AVPs with the 123 'P' disabled were protected. This should have stated enabled. 125 - Added Section 2 which describes the extended AVP Header Format. 127 - Moved the Proxy State AVP to the base protocol. 129 - Changed the description of the Digital-Signature AVP. 131 - The Next-Hop AVP now requires a preceeding Digital-Signature AVP 132 instead of a Host-IP-Address AVP. This change was necessary since 133 the base protocol does not explicitely state that the Host-IP- 134 Address AVP may appear multiple times in a single message. Such a 135 change would be a big departure from the current RADIUS model 136 where the Host-IP-Address contains the IP address of the 137 originator of the message, not the address of intermediate hops. 139 - Fixed various references to sections that were incorrect. 141 - Added clarification about the use of ICV and Digital Signatures 142 within a single message. 144 - Updated the AVP Header flags. 146 - Re-wrote a good portion of section 5.1 ... 148 - ... well, re-wrote a good portion of all everything in section 149 5. 151 - Added a reference to RFC 2459 (x.509 certs) 153 - Added an IANA Considerations section. 155 2.0 Extended AVP Format 157 The DIAMETER Proxy specification introduces a new bit in the AVP 158 flags field of the AVP Header. The following AVP header is used when 159 proxy support is enabled. 161 The attribute format is shown below and MUST be sent in network byte 162 order. 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | AVP Code | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | AVP Length | Cmd Flags |Reservd|P|E|T|V|H|M| 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Vendor ID (opt) | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Tag (opt) | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Data ... 176 +-+-+-+-+-+-+-+-+ 178 Command Flags 180 All Command Codes defined in this spec MUST set all bits in this 181 field to zero (0). 183 AVP Flags 185 The AVP Flags field informs the DIAMETER host how each attribute 186 must be handled. 188 The 'P' bit, known as the protected AVP bit, is used to indicate 189 whether the AVP is protected by a Digital Signature AVP. When set, 190 the AVP is protected and the contents cannot be changed by a 191 DIAMETER proxy server. 193 Note that unless noted, the 'P' bit can be set on any DIAMETER 194 AVP. The Proxy-State AVP MUST not have the 'P' bit set since this 195 AVP will be removed at each hop. Any other AVP that have similar 196 properties (e.g. it will be removed or modified at each hop) MUST 197 NOT have the 'P' bit enabled. 199 When the 'E' bit is enabled it indicates that the AVP data is 200 encrypted using end-to-end encryption. 202 Note that the User-Name AVP [2] MUST NOT have the 'E' bit set 203 since intermediate proxies require the domain information in order 204 to determine the target proxy. 206 3.0 Command Codes 208 This document defines the following DIAMETER Commands. All DIAMETER 209 implementations supporting this extension MUST support all of the 210 following commands: 212 Command Name Command Code 213 ----------------------------------- 214 Domain-Discovery-Request 261 215 Domain-Discovery-Answer 262 217 3.1 Domain-Discovery-Request (DDR) 219 Description 221 The Domain-Discovery-Request message is used by a DIAMETER device 222 wishing to get contact information about a domain's home 223 authentication server as well as to receive password policy 224 information. This message MUST contain the User-Name attribute in 225 order to pass along the user's domain information. 227 It is not necessary for an implementation to issue a DDR in order 228 to make use of a proxy server. 230 The message MUST include either the Host-Name AVP or Host-IP- 231 Address AVP. The X509-Certificate or the X509-Certificate-URL [2] 232 MUST be present in this message in order to inform the home 233 authentication server of the issuing host's certificate. 235 At least one Extension-Id AVP MUST be present in the DDR in order 236 to inform the peer about the locally supported extensions. 238 Message Format 240 ::= 241 242 243 [] 244 245 246 [] 247 [] 248 249 250 { || 251 ::= 326 327 328 [] 329 330 [] 331 332 333 [] 334 [] 335 336 337 { || 338 +------+ ------> +------+ 627 | | | | | | 628 | NASB +--------------------+ DIA2 +--------------------+ DIA1 | 629 | | | | | | 630 +------+ <----- +------+ <------ +------+ 631 (Answer) (Answer) 633 In this example NASB generates a Request that is forwarded to DIA2. 634 The Request contains a Digital-Signature AVP which "protects" all 635 preceeding AVPs bit the 'P' bit set (known as protected AVPs) within 636 the request. All AVPs which may be modified, or removed by 637 intermediate DIAMETRE Proxies MUST NOT have the 'P' bit set. Such 638 AVPs include the Integrity-Check-Vector, Proxy-State, etc. Once DIA2 639 receives the request, it MAY validate the signature in the request to 640 ensure that it was originated by NASB. Verification may not be 641 necessary if the signature was added by a DIAMETER node one hop away 642 since the Integrity-Check-Vector (or any whatever security mechanism 643 used for hop-by-hop security) may be sufficient. 645 The DIA2 Server SHOULD add the Proxy-State AVP [2], which contains 646 opaque data that MUST be present in the response and is used to 647 identify state information related to the request or response. If the 648 Proxy-State AVP is already present in the request, it MUST be 649 replaced with DIA2's Proxy-State AVP. This means that the Proxy-State 650 AVP cannot have the 'P' bit set. The Server MAY also add other new 651 AVPs to the request. All new AVPs that are protected by the new 652 Digital-Signature AVP MUST have the 'P' bit set, and MUST preceed the 653 Digital-Signature AVP. The message is then forwarded towards the DIA1 654 server. 656 The use of link level encryption, such as IPSec, cannot be used for 657 end-to-end message integrity between NASB and DIA1, since all 658 messages are processed by DIA2. What is needed is an application 659 level security mechanism, which is what the Digital-Signature AVP 660 provides. However, Digital-Signatures may not be necessary if the 661 messages do not traverse proxies, unless non-repudiation is required. 663 This mechanism now provides a method for DIA1 to be able to identify 664 that NAS was the initiator of the request, and that no "critial" AVPs 665 were modified mid-stream by intermediate proxies. Therefore, DIA2 666 cannot modify any protected AVPs (such as duration of a call, number 667 of bytes transfered, etc). This mechanism also provides the 668 application with the integrity, and non-repudiation, information it 669 may need should it deem it necessary to log such information. 671 This extension also provides for end-to-end AVP encryption, by using 672 the peer's public key. However, given that asymetric encryption is 673 very costly, it's use should be minimal. 675 An attack has been identified in this proposal which allows a 676 malicous man in the middle attack as shown in the following diagram. 678 (Request) (Request) (Request) 679 +------+ -----> +------+ -----> +------+ -----> +------+ 680 | | | | | | | | 681 | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 | 682 | | | | | | | | 683 +------+ <----- +------+ <----- +------+ <----- +------+ 684 (Answer) (Answer) (Answer) 686 In this example, DIA3 traps packets generated from DIA2 towards DIA1, 687 removes the AVPs added by DIA2 and inserts its own AVPs (possibly by 688 trying to convince DIA1 to pay DIA3 for the services). This attack 689 can be prevented by supporting a new Next-Hop AVP. In this case when 690 NASB prepares a request it inserts a protected Next-Hop AVP which 691 contains DIA2's identitity. DIA2 also adds a Next-Hop AVP with DIA1 692 as the next hop. 694 This mechanism ensures that a man in the middle cannot alter the 695 packet by overriding the previous hop's additions and signature. DIA1 696 could easily validate the packet's path with the use of the Next-Hop 697 AVPs. 699 5.3 Domain Discovery 701 The Domain Discovery message set is very useful in determining the 702 Home authentication server, the password policies for the domain, as 703 a mechanism to retrieve a certificate (or a pointer to a 704 certificate). 706 Note that it is not necessary for a host to issue a Domain Discovery 707 in order to make use of a proxy. A DIAMETER Request MAY be proxied by 708 an intermediate server without the knowledge of the client, however 709 the client will be unable to validate any Digital-Signatures if the 710 home authentication server's certificate or public key is not known. 712 The following example shows a case where DIA1 needs to communicate 713 with DIA3. In this example it is necessary to use DIA2 as a proxy in 714 order for both ISPs to communicate. Although this MAY be desireable 715 in some business models, there are cases where it is beneficial to 716 remove the proxy altogether and allow both DIA3 and DIA1 to 717 communicate in a secure fashion. 719 (DD-Request) (DD-Request) 720 +------+ -----> +------+ ------> +------+ 721 | | | | | | 722 | DIA1 +--------------------+ DIA2 +--------------------+ DIA3 | 723 | | | | | | 724 +------+ <----- +------+ <------ +------+ 725 (DD-Response) (DD-Response) 727 The way the Domain Discovery works is that prior to sending out an 728 authentication request DIA1 would issue a Domain Discovery message 729 towards DIA2. This message is protected with the digital signature as 730 well as the Next-Hop AVP. DIA2 would then forward the request to DIA3 731 including the Next-Hop and the digital signature AVP. 733 When DIA3 receives the request, it MUST save the certificate (or the 734 pointer to the certificate) and respond back including the local 735 password policy, DIA3's certificate, its contact information (i.e. 736 IP address) and protect the response with the digital signature. 738 Note that in all cases the TimeStamp AVP is also present to ensure no 739 replay packets are accepted. 741 When DIA2 receives the packet, it must add the Next-Hop AVP as well 742 as the digital signature AVP. When DIA1 receives the packet it then 743 knows a direct route to communicate with DIA3 since the contact 744 information is present in the response. The fact that both DIA1 and 745 DIA3 can now communicate directly allows both peers to use IPSEC to 746 protect the message exchange (it may be desirable to use the Digital- 747 Signature AVP in instances where records of digitally signed packets 748 must be kept). 750 (Request) 751 +------+ -----> +------+ 752 | | | | 753 | DIA1 +--------------------+ DIA3 | 754 | | | | 755 +------+ <----- +------+ 756 (Answer) 758 In addition, the password policy is also present which can indicate 759 whether DIA3 is willing to accept CHAP, PAP or EAP authentication. 761 Note that the Domain-Discovery-Request/Answer MUST include at least 762 one Extension-Id AVP [2]. 764 5.4 Data Integrity 766 This section will describe how data integrity and non-repudiation is 767 achieved using the Digital-Signature AVP. 769 Note that the Timestamp and Nonce AVPs MUST be present in the message 770 PRIOR to the Digital-Signature AVPs discussed in this section. The 771 Timestamp AVP provides replay protection and the Nonce AVP provides 772 randomness. 774 5.4.1 Using Digital Signatures 776 In the case of a simple peer to peer relationship the use of IPSEC is 777 sufficient for data integrity and confidentiality. However there are 778 instances where a peer must communicate with another peer through the 779 use of a proxy server. IPSEC does not provide a mechanism to protect 780 traffic when two peers must use an intermediary node to communicate 781 at the application layer therefore the Digital-Signature AVP MUST be 782 used. 784 The following diagram shows an example of a router initiating a 785 DIAMETER message to DIA1. Once DIA1 has finished processing the 786 message it adds its signature and forwards the message to the non- 787 trusted DIA2 proxy server. If DIA2 needs to add or change any 788 protected AVPs it SHOULD add its digital signature before forwarding 789 the message to DIA3. 791 +------+ -----> +------+ -----> +------+ -----> +------+ 792 | | | | | non- | | | 793 |router+----------+ DIA1 +----------+trustd+----------+ DIA3 | 794 | | | | | DIA2 | | | 795 +------+ <----- +------+ <----- +------+ <----- +------+ 797 Since intermediate DIAMETER proxies may add, or delete unprotected 798 AVPs "en route" towards the final DIAMETER destination, it is 799 necessary for the length in the header to be set to zero (0) prior to 800 the signature computation. The length field must be restored once the 801 computation is complete. 803 The following is an example of a message that include end-to-end 804 security: 806 ::= 807 808 [] 809 810 811 812 814 The AVP Header's 'P' bit is used to identify which AVPs are 815 considered protected when applying a digital signature to a DIAMETER 816 message. Protected AVPs cannot be changed "en route" since they are 817 protected by the Digital Signature AVP. All protected AVPs added by a 818 DIAMETER entity MUST appear prior to the new Digital Signature AVP. 820 The Next-Hop AVP indicates the intended recipient of the DIAMETER 821 message. When a DIAMETER message is received with a Next-Hop AVP 822 that does not correspond with the address information with the 823 preceeding Digital-Signature AVP, the message MUST be considered 824 invalid and MUST be rejected. The Next-Hop AVP MUST be protected. 826 The Data field of the Digital-Signature AVP contains the RSA/MD5 827 signature algorithm as defined in [9]. 829 5.4.2 Using Mixed Data Integrity AVPs 831 The previous sections described the Integrity-Check-Vector and the 832 Digital-Signature AVP. Since the ICV offers hop-by-hop integrity and 833 the digital signature offers end to end integrity, it is possible to 834 use both AVPs within a single DIAMETER message. In fact, the use of 835 the ICV and the Digital-Signature is recommended to provide both 836 types of message integrity, which is necessary when messages are 837 proxied. In the event that two peers use an out-of-band message 838 integrity mechanism (e.g. IPSec) for hop-by-hop message integrity, 839 the ICV AVP is not necessary and should not be used. 841 The following diagram provides an example where DIAMETER Server 1 842 (DIA1) communicates with DIA3 using Digital-Signatures through DIA2. 843 In this example ICVs are used between DIA1 and DIA2 as well as 844 between DIA2 and DIA3. 846 847 -----------------------------> 848 849 +------+ -----> +------+ -----> +------+ 850 | | | | | | 851 | DIA1 +----------+ DIA2 +----------+ DIA3 | 852 | | | | | | 853 +------+ +------+ +------+ 855 Using the previous diagram, the following message would be sent 856 between DIA1 and DIA2: 858 ::= 859 860 [] 861 862 863 864 DIA2)> 866 The following message would be sent between DIA2 and DIA3: 868 ::= 869 870 [] 871 872 873 874 875 876 DIA3)> 878 Note that in the above example messages the ICV AVP appear after the 879 Digital-Signature AVP. This is necessary since DIA2 above removes the 880 ICV AVP (DIA1->DIA2) and adds its own ICV AVP (DIA2->DIA3). The ICVs 881 provide hop-by-hop security while the Digital-Signature provides 882 integrity of the message between DIA1 and DIA3. 884 885 ----------------------------> 886 887 +------+ -----> +------+ -----> +------+ -----> +------+ 888 | | | | | | | | 889 |router+----------+ DIA1 +----------+ DIA2 +----------+ DIA2 | 890 | | | | | | | | 891 +------+ <----- +------+ <----- +------+ <----- +------+ 893 There are cases, such as in remote access, where the device 894 initiating the DIAMETER request does not have the processing power to 895 generate Digital-Signatures as required by the protocol. In such an 896 arrangement, there normally exists a first hop DIAMETER Server (DIA1) 897 which acts as a proxy to relay the request to the final 898 authenticating DIAMETER server (DIA2). It is valid for the first hop 899 server to remove the Integrity-Check-Vector AVP inserted by the 900 router and replace it with a Digital-Signature AVP. 902 5.5 AVP Encryption with Public Keys 904 AVP encryption using public keys is much more complex than the 905 previously decribed method, yet it is desirable to use it in cases 906 where the DIAMETER message will be processed by an untrusted 907 intermediate node (proxy). 909 Public Key encryption SHOULD be supported, however it is permissible 910 for a low powered device initiating the DIAMETER message to use 911 shared secret encryption with the first hop (proxy) DIAMETER server, 912 which would decrypt and encrypt using the Public Key method. 914 The PK-Encrypted-Data bit MUST only be set if the final DIAMETER host 915 is aware of the sender's public key. This information can be relayed 916 in three different methods as described in section 5.6. 918 The AVP is encrypted in the method described in [9]. 920 5.6 Public Key Cryptography Support 922 A DIAMETER peer's public key is required in order to validate a 923 message which includes the the Digital-Signature AVP. There are three 924 possibilities on retrieving public keys: 926 5.6.1 X509-Certificate 928 A message which includes a Digital-Signature MAY include the 929 X509-Certificate AVP. Given the size of a typical certificate, this 930 is very wasteful and in most cases DIAMETER peers would cache such 931 information in order to minimize per packet processing overhead. 933 It is however valid for a DIAMETER host to provide its 934 X509-Certificate in certain cases, such as when issuing the Device- 935 Reboot-Indication, or in the Domain-Discovery messages. It is 936 envisioned that the peer would validate and cache the certificate at 937 that time. 939 5.6.2 X509-Certificate-URL 941 The X509-Certificate-URL is a method for a DIAMETER host sending a 942 message that includes the Digital-Signature to provide a pointer to 943 its certificate. 945 Upon receiving such a message a DIAMETER host MAY choose to retrieve 946 the certificate if it is not locally cached. Of course the process of 947 retrieving and validating a certificate is lengthy and will require 948 the initiator of the message to retransmit the request. However once 949 cached the certificate can be used until it expires. 951 5.6.3 Static Public Key Configuration 953 Given that using certificates requires a PKI infrastructure which is 954 very costly, it is also possible to use this technology by locally 955 configuring DIAMETER peers' public keys. 957 Note that in a network involving many DIAMETER proxies this may not 958 scale well. 960 6.0 IANA Considerations 962 The numbers for the Command Code AVPs (section 3) is taken from the 963 numbering space defined for Command Codes in [2]. The numbers for the 964 various AVPs defined in section 4 were taken from the AVP numbering 965 space defined in [2]. The numbering for the AVP and Command Codes 966 MUST NOT conflict with values specified in [2] and other DIAMETER 967 related Internet Drafts. 969 This document also introduces two new bits to the AVP Header, which 970 MUST NOT conflict with the base protocol [2] and any other DIAMETER 971 extension. 973 7.0 References 975 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 976 [2] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft, 977 draft-calhoun-diameter-08.txt, August 1999. 978 [3] Rivest, Dusse, "The MD5 Message-Digest Algorithm", 979 RFC 1321, April 1992. 980 [4] Kaufman, Perlman, Speciner, "Network Security: Private 981 Communications in a Public World", Prentice Hall, 982 March 1995, ISBN 0-13-061466-1. 983 [5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 984 Authentication", RFC 2104, January 1997. 985 [6] Calhoun, Bulley, "DIAMETER User Authentication Extensions", 986 draft-calhoun-diameter-authen-06.txt, August 1999. 987 [7] Aboba, Beadles "The Network Access Identifier." RFC 2486. 988 January 1999. 989 [8] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", 990 RFC 2477, January 1999. 991 [9] Kaliski, "PKCS #1: RSA Encryption Version 1.5", Internet- 992 Draft, draft-hoffman-pkcs-rsa-encrypt-03.txt, October 1997. 993 [10] Calhoun, Zorn, Pan, "DIAMETER Framework", 994 draft-calhoun-diameter-framework-02.txt, Work in Progress, 995 December 1998. 996 [11] Aboba, Vollbrecht, "Proxy Chaining and Policy Implementation in 997 Roaming", RFC 2607, June 1999. 998 [12] Housley, Ford, Polk, Solo, "Internet X.509 Public Key 999 Infrastructure Certificate and CRL Profile", RFC 2459, 1000 January 1999. 1001 [13] S. Bradner, "Key words for use in RFCs to Indicate 1002 Requirement Levels", BCP 14, RFC 2119, March 1997. 1004 8.0 Acknowledgements 1006 The Authors would like to acknowledge the following people for their 1007 contribution in the development of the DIAMETER protocol: 1009 Bernard Aboba, Jari Arkko, , Daniel C. Fox, Lol Grant, Nancy Greene, 1010 Peter Heitman, Ryan Moats, Victor Muslin, Kenneth Peirce, Allan 1011 Rubens, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn 1013 9.0 Author's Address 1015 Questions about this memo can be directed to: 1017 Pat R. Calhoun 1018 Network and Security Research Center, Sun Labs 1019 Sun Microsystems, Inc. 1020 15 Network Circle 1021 Menlo Park, California, 94025 1022 USA 1024 Phone: 1-650-786-7733 1025 Fax: 1-650-786-6445 1026 E-mail: pcalhoun@eng.sun.com 1028 William Bulley 1029 Merit Network, Inc. 1030 4251 Plymouth Road, Suite C 1031 Ann Arbor, Michigan, 48105-2785 1032 USA 1034 Phone: 1-734-764-9993 1035 Fax: 1-734-647-3185 1036 E-mail: web@merit.edu 1038 10.0 Full Copyright Statement 1040 Copyright (C) The Internet Society (1999). All Rights Reserved. 1042 This document and translations of it may be copied and furnished 1043 to others, and derivative works that comment on or otherwise 1044 explain it or assist in its implmentation may be prepared, copied, 1045 published and distributed, in whole or in part, without 1046 restriction of any kind, provided that the above copyright notice 1047 and this paragraph are included on all such copies and derivative 1048 works. However, this docu- ment itself may not be modified in any 1049 way, such as by removing the copyright notice or references to the 1050 Internet Society or other Inter- net organizations, except as needed 1051 for the purpose of developing Internet standards in which case 1052 the procedures for copyrights defined in the Internet Standards 1053 process must be followed, or as required to translate it into 1054 languages other than English. The limited permis- sions granted 1055 above are perpetual and will not be revoked by the Internet 1056 Society or its successors or assigns. This document and the 1057 information contained herein is provided on an "AS IS" basis and 1058 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 1059 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1060 LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN 1061 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1062 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."