Internet DRAFT - draft-aravind-radext-endtoend-attribute-security
draft-aravind-radext-endtoend-attribute-security
RADIUS EXTensions Working Group Aravind Prasad Sridharan
INTERNET-DRAFT Sanal Kumar Kariyezhath Sivaraman
Intended Status: Standards Track DELL
Expires: February 19, 2018 August 18, 2017
RADIUS End-to-end Attribute Security
draft-aravind-radext-endtoend-attribute-security-00
Abstract
This document proposes a method to provide end to end security to
Attributes in RADIUS Messages.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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
Aravind, et al. Expires February 19, 2018 [Page 1]
INTERNET DRAFT RADIUS Attribute Security August 18, 2017
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.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Problem Scenario . . . . . . . . . . . . . . . . . . . . . . . 2
3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Security Attribute . . . . . . . . . . . . . . . . . . . . 4
3.2 Overall Message Flow: . . . . . . . . . . . . . . . . . . . 4
3.3 Scenarios when NAS is used as transit . . . . . . . . . . . 6
4 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1 Normative References . . . . . . . . . . . . . . . . . . . 7
7.2 Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1 Introduction
In a typical scenario, there could be multiple RADIUS proxies between
NAS and RADIUS server. RADIUS ensures hop to hop security by using
pre-shared secret between hops. End to end connection between NAS and
RADIUS server is through the set of transitive links involving
proxies. RADIUS over TLS can be deployed to have the security between
hop to hop only. Incase of Roaming scenarios, the NAS, proxies and
home server will typically be managed by different administrative
entities. Proxies have complete access to messages exchanged between
NAS and RADIUS Server.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2 Problem Scenario
No end to end security in RADIUS. Security Mechanism like Radius over
TLS provides only Hop to Hop security.
Aravind, et al. Expires February 19, 2018 [Page 2]
INTERNET DRAFT RADIUS Attribute Security August 18, 2017
As the proxy has the right to modify the message, that introduces
following security threats [RFC2607].
Message editing
Attribute editing
Theft of password
Theft and modification of accounting data
Replay attacks
Connection hijacking
Fraudulent accounting.
Both NAS and RADIUS Server are not aware of the changes made in the
message by the proxies and assumed to be in trusted relationship with
proxies in Proxy chaining scenarios. This can cause havoc in roaming
environments.
3 Solution
Introduce a new Security Attribute TLV as a container that will hold
the set of sensitive attributes as sub TLVs. The sensitive attributes
may be any of the to-be-protected RADIUS attributes like Framed-
Protocol, Service-Type and so on. This Security attribute TLV will
be protected using already existing EAP-TLS mechanism. This is to
leverage all the advantages EAP-TLS already provides in terms of
security.
Initially, EAP -TLS exchange will happen between the RADIUS Client
and Server and after the EAP-TLS handshake, the symmetric key will be
exchanged. This key is used to protect the sensitive RADIUS
attributes from the attack from in-between Proxies. With this, the
end-to-end RADIUS attribute security is achieved.
The set of sensitive attributes to be protected can be configured at
the NAS and RADIUS Server. The attribute sets at both ends can be
different. This attribute will be encrypted using the symmetric key
that is agreed between both Client and Server in EAP-TLS.
After receiving TLS finished message from the Server, this attribute
will be sent along with EAP Response to Server. The Server can be
configured to expect the Security Attribute TLV for specific set of
users and incase of its absence, it can drop the RADIUS Message. The
Server will send back EAP Success/Failure along with sensitive
attributes placed as sub TLVs inside the Attribute TLV encrypted
using the symmetric key.
Aravind, et al. Expires February 19, 2018 [Page 3]
INTERNET DRAFT RADIUS Attribute Security August 18, 2017
3.1 Security Attribute
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Attribute(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD
Length
1
Sub-Attributes
This can includes all the to-be-protected RADIUS attributes.
3.2 Overall Message Flow:
In the case where the EAP-TLS mutual authentication is successful,
the conversation will appear as follows:
Client Server
------ ------
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
Aravind, et al. Expires February 19, 2018 [Page 4]
INTERNET DRAFT RADIUS Attribute Security August 18, 2017
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS,
Security Attribute TLV ->
<- EAP-Success,
Security Attribute TLV
In the case where the server authenticates to the peer successfully,
but the peer fails to authenticate to the server, the conversation
will appear as follows:
Client Server
------ ------
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
Aravind, et al. Expires February 19, 2018 [Page 5]
INTERNET DRAFT RADIUS Attribute Security August 18, 2017
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Request
EAP-Type=EAP-TLS
(TLS Alert message)
EAP-Response/
EAP-Type=EAP-TLS,
Security Attribute TLV ->
<- EAP-Failure,
Security Attribute TLV
3.3 Scenarios when NAS is used as transit
Incase of a typical 802.1x scenario, the message exchange will happen
between the Supplicant/Client and RADIUS server using the NAS/RADIUS
Client as transit. In such cases, when the EAP Response is received
from Supplicant, the EAP TLS Handshake will happen between NAS and
RADIUS Server. Then, the EAP attribute is encapsulated within the
Attribute TLV and encrypted and sent to Server. From then on, when
the received Response from Server has Attribute TLV which in turn
contains EAP message, the NAS will forward the EAP back to
Client/Supplicant. Hence, the property of NAS being pass-through
device remains and no additional modifications are required.
4 Advantages
Rogue Proxy cannot decrypt the protected Security Attribute contents.
Hence, security in Roaming scenarios is assured.
Concept of un-modifiable or protected attributes is introduced. With
this, it is possible to exchange sensitive attributes safely between
NAS/RADIUS Client and RADIUS Server.
Even if any Rogue proxy removes the Security Attribute, RADIUS server
or NAS can potentially drop the message as the Security Attribute is
expected in the message with respect to configuration.
Both NAS and RADIUS Server can safely assume the trust relationships
with proxies.
Since, end-to-end security is accomplished along with EAP-TLS in this
mechanism, all merits of EAP-TLS like Mutual authentication,
Integrity protection, Replay protection, Confidentiality, Dictionary
attack protection and Fragmentation are provided by default.
Aravind, et al. Expires February 19, 2018 [Page 6]
INTERNET DRAFT RADIUS Attribute Security August 18, 2017
5 Security Considerations
This document does not introduce any new security concerns to RADIUS
or any other specifications referenced in this document
6 IANA Considerations
This document requests IANA to allocate the new type code value to
the proposed Security Attribute and add it to the list of existing
RADIUS Attributes.
7 References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
[RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines",
BCP 158, RFC 6158, March 2011.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929,
April 2013.
7.2 Informative References
[RFC5216] Simon D., Aboba B., Hurst S., "The EAP-TLS Authentication
Protocol", RFC5216, March 2008.
[RFC2607] Abobam B., Vollbrecht J., "Proxy Chaining and Policy
Implementation in Roaming", RFC2607, June 1999.
[RFC6613] DeKok, A., "RADIUS over TCP", May 2012.
[RFC2868] Zorn, G., Leifer, D., Rubens A., Shriver, J.,
Holdrege, M., Goyret, I, "RADIUS Attributes for Tunnel
Protocol Support", June 2000
Aravind, et al. Expires February 19, 2018 [Page 7]
INTERNET DRAFT RADIUS Attribute Security August 18, 2017
[RFC6929] DeKok, A. and Lior , A., "Remote Authentication Dial-In
User Service RADIUS) Protocol Extensions", April 2013.
[RFC5080] Nelson, D. and DeKok. A., "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes"
[RFC2867] Zorn, G., Aboba, B. and Mitton, D., "RADIUS Accounting
Modifications for Tunnel Protocol Support", June 2000.
[RFC5997] DeKok. A., "Use of Status-Server Packets in the
Remote Authentication Dial In User Service (RADIUS)
Protocol", August 2010.
Authors' Addresses
Aravind Prasad Sridharan
DELL
Olympia Technology Park
Guindy, Chennai 600032
India
Phone: +91 9884612715
Email: aravind.sridharan@dell.com
Sanal Kumar Kariyezhath Sivaraman
DELL
Olympia Technology Park
Guindy, Chennai 600032
India
Phone: +91 9600081365
Email: Sanal_Kumar_Sivarama@dell.com
Aravind, et al. Expires February 19, 2018 [Page 8]
