idnits 2.17.1 draft-abhi-eap-radius-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 177 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 48 has weird spacing: '...ver and pass ...' -- 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) == Missing Reference: 'RFC2607' is mentioned on line 71, but not defined == Missing Reference: 'RFC2865' is mentioned on line 71, but not defined == Missing Reference: 'RFC3162' is mentioned on line 71, but not defined == Unused Reference: 'RFC 3748' is defined on line 146, but no explicit reference was found in the text == Unused Reference: 'RFC 4306' is defined on line 149, but no explicit reference was found in the text == Unused Reference: 'RFC 2869' is defined on line 151, but no explicit reference was found in the text == Unused Reference: 'RFC 2284' is defined on line 153, but no explicit reference was found in the text == Unused Reference: 'RFC 2716' is defined on line 155, but no explicit reference was found in the text == Unused Reference: 'RFC 2607' is defined on line 158, but no explicit reference was found in the text == Unused Reference: 'RFC 2865' is defined on line 160, but no explicit reference was found in the text == Unused Reference: 'RFC 3162' is defined on line 162, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Downref: Normative reference to an Informational RFC: RFC 2869 ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2716 (Obsoleted by RFC 5216) ** Downref: Normative reference to an Informational RFC: RFC 2607 Summary: 11 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Abhishek Singh 3 SafeNet Infotech Pvt. Ltd. 5 Secure Communication of EAP - Radius messages. 6 draft-abhi-eap-radius-00.txt 8 By submitting this Internet-Draft, each author represents 9 that any applicable patent or other IPR claims of which he 10 or she is aware have been or will be disclosed, and any of 11 which he or she becomes aware will be disclosed, in accordance 12 with Section 6 of BCP 79." 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note 16 that other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 EAP is used to establish secure communication channel in 33 IKEv2 and in Wireless Security. EAP-TLS, EAP-TTLS, EAP-MD5, 34 EAP-SIM uses radius protocol for communication bewteen 35 radius server and the client. These protocols are used in 36 both Wireless network authentication and in IKEV2 authentication 37 to establish VPN tunnel. 39 +----------+ +----------+ +----------+ 40 | | EAPOL | EAP | RADIUS | | 41 | EAP |<------>| Server |<------>| RADIUS | 42 | Client | EAPOW | | (EAP) | Server | 43 | | | | | | 44 +----------+ +----------+ +----------+ 46 This draft presents the security protocol which can be used 47 to establish the secure communication channel between the 48 radius server and pass through server. Pass through server 49 is access point in the case of wireless communication and 50 it is gateway in case of IKEV2 authnetication. 52 Table of Content 54 1.0 Introduction ......................................2.0 55 2.0 Secure Message Exchange............................3.0 56 References ............................................4.0 57 Authors Address .......................................5.0 58 Full Copyright Statement ..............................5.0 60 1 Introduction 62 Extensible Authentication Protocol(EAP), rfc2284, is a general 63 protocol that allows network access points to support multiple 64 authentication methods. RADIUS attribute used for EAP is EAP-Message 65 79 (rfc2869). RADIUS communicates all EAP messages by embedding them in 66 this attribute. 68 RADIUS/EAP is used in order to provide authentication and authorization 69 for network access. As a result, both the RADIUS and EAP portions of the 70 conversation are potential targets of an attack. Threats are discussed 71 in [RFC2607], [RFC2865], and [RFC3162]. 73 Some of the serious problem with the Radius Packet include: 75 [1]An adversary may attempt to acquire confidential data and 76 identities by snooping RADIUS packets. For example in case of 77 IKEv2, EAP-TLS authentication, the confidetial data can be 78 shared keys which is generated after EAP-TLS authentication. 79 The shared keys is transferred by the Radius Server to the 80 EAP Server and is further used by EAP server for the generation 81 of AUTH. 83 [2]An adversary may attempt to modify packets containing RADIUS 84 messages. 86 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 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | Code | Identifier | Length | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | | 91 | Response Authenticator | 92 | | 93 | | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Attributes ... 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 Figure 1.0 Showing the Radius packet 100 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 102 | Type | Length | Value ..... 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 105 Figure 2.0 Attributes containing the following Structure 107 2. The Secure message exchange between the Radius and 108 the Pass through Server. 110 EAP Server Radius Server 111 ---------- -------------- 113 Public_Key_of_EAP_Server 114 --------------------------> 116 Public_key_of_Radius_Server 117 <---------------------------- 119 Encrypt_date_with_pubic_key_Radius 120 ----------------------------------> 122 Encrypt_data_with_Public_key_EAP_Server 123 <----------------------------------------- 125 EAP Server must have the public keys of the Radius server 126 and the Radius server must have the public keys of the EAP. 127 The exchange of the public keys can be done in message 128 exchanges between the EAP server and Radius or it can be 129 done manually. The public keys must encrypt the value field. 130 If the packet shown in figure 1.0 is streamed from the EAP server, 132 the public keys of the Radius server must encrypt the value field 133 shown in figure 2.0. This packet when reaches the Radius server, 134 the value field is decrypted with the private keys of the radius. 135 Similarly, for the packets, which are getting streamed by the 136 Radius Server, the value field must be encrypted by the public 137 keys of the EAP server and is decrypted by the private keys of 138 the EAP server. 140 The above mention procedure will ensure that the value field shown 141 in figure 2.0 is encrypted and hence will prevent the compromise and 142 modification of the confidential data in the radius packets. 144 3. References 146 [RFC 3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 147 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 148 3748, June 2004. 149 [RFC 4306] C. Kaufman, "Internet key Exchange Protocol (Ikev2 150 protocol)" 151 [RFC 2869] C.Rigney, Livingston, W.Willats, P.Calhoun "RADIUS 152 Extensions", June 2000. 153 [RFC 2284] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication 154 Protocol (EAP)", March 1998 155 [RFC 2716] B. Aboba, D. Simons, "PPP EAP TLS Authentication Protocol", 156 October 1999. 158 [RFC 2607] B.Abobaba, J. Vollbertcht, "Proxy Chaining and Policy 159 Implementation in Roaming", June 1999. 160 [RFC 2865] C. RIgney, S. Willens, A. Rubens, W.Simpson, "Remote 161 Authentication Dial in User Service ", June 2000. 162 [RFC 3162] B.Aboba, G.Zorn, D.Mitton, "Radius and IPv6", August 2001. 164 Author's Address 165 ---------------- 166 Abhishek Singh 167 SafeNet InfoTech Pvt. Ltd. 168 Logix TechnoPark 169 5th & 6th Floor, Plot No.5 170 Sector - 127 171 Taj Express Way 172 Noida - 201301. U.P. 173 Email: asingh3@in.safenet-inc.com 174 abhicc285@gmail.com 175 Phone : 9899835649 177 Copyright (C) The IETF Trust (2008) 178 ------------------------------------- 180 This document is subject to the rights, licenses and restrictions 181 contained in BCP 78, and except as set forth therein, the authors 182 retain all their rights." 184 "This document and the information contained herein are provided on an 185 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 186 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 187 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 188 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 189 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 190 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."