Internet DRAFT - draft-abhi-eap-radius

draft-abhi-eap-radius



                                   
                                 Abhishek Singh
                                 SafeNet Infotech Pvt. Ltd.
                                 

 
   Secure Communication of EAP - Radius messages.
          draft-abhi-eap-radius-00.txt



By submitting this Internet-Draft, each author represents 
that any applicable patent or other IPR claims of which he
or she is aware have been or will be disclosed, and any of
which he or she becomes aware will be disclosed, in accordance
with Section 6 of BCP 79."

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note 
that other groups may also distribute working documents as 
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six 
months and may be updated, replaced, or obsoleted by other 
documents at any time.  It is inappropriate to use Internet-Drafts 
as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
 http://www.ietf.org/ietf/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
 http://www.ietf.org/shadow.html


Abstract


EAP is used to establish secure communication channel in 
IKEv2 and in Wireless Security. EAP-TLS, EAP-TTLS, EAP-MD5, 
EAP-SIM uses radius protocol for communication bewteen 
radius server and the client. These protocols are used in 
both Wireless network authentication and in IKEV2 authentication 
to establish VPN tunnel. 



   +----------+        +----------+        +----------+
   |          |  EAPOL |  EAP     | RADIUS |          |
   |  EAP     |<------>|  Server  |<------>|  RADIUS  |
   |  Client  |  EAPOW |          |  (EAP) |  Server  |
   |          |        |          |        |          |
   +----------+        +----------+        +----------+


This draft presents the security protocol which can be used 
to establish the secure communication channel between the 
radius server and  pass through server. Pass through server 
is access point in the case of wireless communication and 
it is gateway in case of IKEV2 authnetication.

                                                      [page 1]




Table of Content

1.0 Introduction ......................................2.0
2.0 Secure Message Exchange............................3.0
References ............................................4.0
Authors Address .......................................5.0
Full Copyright Statement ..............................5.0


1 Introduction


 Extensible Authentication Protocol(EAP), rfc2284, is a general 
protocol that allows network access points to support multiple 
authentication methods. RADIUS attribute used for EAP is EAP-Message 
79 (rfc2869). RADIUS communicates all EAP messages by embedding them in 
this attribute.

 RADIUS/EAP is used in order to provide authentication and authorization 
for network access.  As a result, both the RADIUS and EAP portions of the 
conversation are potential targets of an attack. Threats are discussed 
in [RFC2607], [RFC2865], and [RFC3162].
 
Some of the serious problem with the Radius Packet include:



[1]An adversary may attempt to acquire confidential data and
   identities by snooping RADIUS packets.  For example in case of 
   IKEv2, EAP-TLS authentication, the confidetial data can be
   shared keys which is generated after EAP-TLS authentication.
   The shared keys is transferred by the Radius Server to the
   EAP Server and is further used by EAP server for the generation 
   of AUTH.



[2]An adversary may attempt to modify packets containing RADIUS
   messages.






                                                           [page 2]








  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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Code      |  Identifier   |            Length             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                     Response Authenticator                    |
  |                                                               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Attributes ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 1.0 Showing the Radius packet 

 
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 |     Type      |    Length     |  Value .....
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Figure 2.0 Attributes containing the following Structure


2. The Secure message exchange between the Radius and 
    the Pass through Server. 


  EAP Server                         Radius Server  
  ----------                         --------------

  Public_Key_of_EAP_Server 
 -------------------------->

                            Public_key_of_Radius_Server  
                           <----------------------------

Encrypt_date_with_pubic_key_Radius
---------------------------------->  

                        Encrypt_data_with_Public_key_EAP_Server
                        <-----------------------------------------


EAP Server must have the public keys of the Radius server 
and the Radius server must have the public keys of the EAP. 
The exchange of the public keys can be done in message 
exchanges between the EAP server and Radius or it can be 
done manually. The public keys must encrypt the value field. 
If the packet shown in figure 1.0 is streamed from the EAP server, 

                                                             [page 3]

the public keys of the Radius server must encrypt the value field
shown in figure 2.0. This packet when reaches the Radius server, 
the value field is decrypted with the private keys of the radius.
Similarly, for the packets, which are getting streamed by the 
Radius Server, the value field must be encrypted by the public 
keys of the EAP server and is decrypted by the private keys of 
the EAP server.

The above mention procedure will ensure that the value field shown
in figure 2.0 is encrypted and hence will prevent the compromise and
modification of the confidential data in the radius packets.


3. References



[RFC 3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
           Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
           3748, June 2004.
[RFC 4306] C. Kaufman, "Internet key Exchange Protocol (Ikev2
           protocol)"
[RFC 2869] C.Rigney, Livingston, W.Willats, P.Calhoun "RADIUS
           Extensions", June 2000.
[RFC 2284] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication
           Protocol (EAP)", March 1998
[RFC 2716] B. Aboba, D. Simons, "PPP EAP TLS Authentication Protocol",
           October 1999.
                                                                       
[RFC 2607] B.Abobaba, J. Vollbertcht, "Proxy Chaining and Policy
           Implementation in Roaming", June 1999.
[RFC 2865] C. RIgney, S. Willens, A. Rubens, W.Simpson, "Remote
           Authentication Dial in User Service ", June 2000.
[RFC 3162] B.Aboba, G.Zorn, D.Mitton, "Radius and IPv6", August 2001.














                                                              [page 4]


Author's Address
----------------
  Abhishek Singh
  SafeNet InfoTech Pvt. Ltd.
  Logix TechnoPark
  5th & 6th Floor, Plot No.5
  Sector - 127
  Taj Express Way
  Noida - 201301. U.P.
  Email: asingh3@in.safenet-inc.com
         abhicc285@gmail.com
  Phone : 9899835649




 Copyright (C) The IETF Trust (2008)
 -------------------------------------


This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights."

"This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

                                                         [page 5]