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]