ROAMOPS Working Group Pat Calhoun
INTERNET-DRAFT Sun Microsystems
Category: Standards Track Bernard Aboba
<draft-ietf-roamops-roamsec-02.txt> Microsoft
20 July 1998
End-to-End Security in Roaming
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing 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 mate-
rial or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as <draft-
ietf-roamops-roamsec-02.txt>, and expires January 15, 1999. Please
send comments to the authors.
2. Abstract
As noted in Roaming Requirements, there is a need for end-to-end secu-
rity in roaming, including end-to-end integrity protection, and confi-
dentiality. In roaming implementations based on proxy chaining, pack-
ets are routed between the NAS and home server through a series of
proxies. Current roaming implementations provide only hop-by-hop
security, guarding only against modification of packets in transit
between hops. This makes it possible for untrusted proxies to modify
packets sent between a NAS and a home server without detection, as
well as to decrypt PAP passwords, Tunnel passwords, and other hidden
attributes which are available to it in cleartext.
This document provides a framework for end-to-end security in roaming,
making it possible to provide end-to-end message integrity and
attribute hiding through addition of three new attributes.
3. Introduction
As noted in [2], there is a need for end-to-end security in roaming,
including end-to-end integrity protection, and confidentiality. In
Calhoun & Aboba [Page 1]
INTERNET-DRAFT 20 July 1998
roaming implementations based on proxy chaining, packets are routed
between the NAS and home server through a series of proxies. Current
roaming implementations, as described in [1] provide only hop-by-hop
security, guarding only against modification of packets in transit
between hops. This makes it possible for untrusted proxies to modify
packets sent between a NAS and a home server without detection, as
well as to decrypt PAP passwords, Tunnel passwords, and other hidden
attributes which are available to proxies in cleartext.
This document provides a framework for end-to-end security in roaming,
making it possible to provide end-to-end message integrity and
attribute hiding through addition of three new attributes, Security-
Parameter-Index, Hidden and End-to-End-Signature. In this document,
it is assumed that a key has previously been established between the
two endpoints. It is this key which is used in calculation of the mes-
sage integrity check, as well as in end-to-end encryption of
attributes. Future documents will discuss key exchange issues.
The Security-Parameters-Index attribute is used to identify the secu-
rity association within which the End-to-End-Signature and Hidden
attributes are to be evaluated. Note that in the case where an inter-
mediate proxy implements policy, it is possible for a security associ-
ation to be established between the intermediate proxy and the home
server, NAS, or local proxy. For example, an intermediate proxy may
immediately send an Access-Reject to the NAS in response to an Access-
Request, without having first forwarded it to the home server. In this
case, the intermediate proxy and NAS would need to establish a secu-
rity association in order to permit verification of the authenticity
of the Access-Reject.
Using the Hidden attribute, it is possible for the client or server to
protect an attribute end-to-end. This is accomplished by encapsulating
and then encrypting another attribute within the Hidden attribute.
Using the End-to-End-Signature attribute, it is possible for a client
or server to provide a keyed MAC which will allow end-to-end integrity
protection. The keyed MAC is calculated over the immutable portions of
the packet header, as well as all of the attributes preceeding the
End-to-End-Signature attribute. This makes it possible for some or all
of the attributes in the packet to be protected, at the sender's dis-
cretion.
While a proxy may add, delete or modify unprotected attributes, it
MUST NOT add, delete or modify protected attributes so that the valid-
ity of the keyed MAC can be maintained. A proxy also MUST NOT modify
an End-to-End-Signature or Hidden attribute. On receiving a packet
including an End-to-End-Signature attribute, an end system implement-
ing end-to-end security MUST check the validity of the message
integrity check and MUST silently discard the packet if the message
integrity check cannot be verified.
By allowing the message integrity check to be applied to a subset of
attributes selected by the sender, and by allowing attributes to be
hidden individually, these extensions enable end-to-end security
Calhoun & Aboba [Page 2]
INTERNET-DRAFT 20 July 1998
functionality while at the same time enabling proxies to continue to
implement policy. As described in [8], policy function is a central
part of the roaming architecture since roaming is inherently an inter-
domain activity.
4. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [7].
5. Transition
Since NAS devices will not initially implement the End-to-End-Signa-
ture and Hidden attributes, it is envisaged that these attributes will
initially be deployed on local proxies and home servers. In this sce-
nario, the local proxy will be configured to employ end-to-end secu-
rity for those NAS devices that do not support this. In this case, the
local proxy would add End-to-End security attributes to Access-
Requests destined for the home server and would process End-to-End
security attributes in an Access-Accept, Access-Reject or Access-Chal-
lenge originated by the home server.
Note that if a NAS is end-to-end security enabled, then the local
proxy will receive an Access-Request from the NAS with an End-to-End-
Signature and will not need to add its own. As a result, a packet
should include at most one End-to-End-Signature attribute. A packet
may contain more than one Hidden attribute.
6. Proposed attributes
6.1. Security-Parameter-Index
Description
The purpose of the Security-Parameter-Index attribute is to iden-
tify the security association within which the End-to-End-Signature
and Hidden attributes should be evaluated.
A summary of the Security-Parameter-Index attribute is shown below.
The fields are transmitted from left to right.
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun & Aboba [Page 3]
INTERNET-DRAFT 20 July 1998
Type
? for Security-Parameter-Index
Length
6
Value
The Value field is four octets. This serves as an index identifying
the security association established between the two end-points.
6.2. End-to-End-Signature
Description
This attribute provides for the use of a keyed-MAC to be verified
end-to-end.
A summary of the End-to-End Signature attribute is shown below.
The fields are transmitted from left to right.
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Protocol | String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
? for End-to-End-Signature
Length
19 (protocol 1)
Protocol
The protocol field specifies the authentication algorithm to be
used in computing the message authentication code (MAC) which is
placed in the string field.
If the protocol field is 1, the HMAC protocol, described in [6]
is used, along with the MD5 algorithm described in [5]. All
implementations MUST support HMAC-MD5. No other protocol values
are defined.
String
The End-to-End-Signature is an calculated using the algorithm
Calhoun & Aboba [Page 4]
INTERNET-DRAFT 20 July 1998
specified in the protocol field. The MAC is computed over the
portion of the RADIUS packet from the beginning until the end of
the End-to-End-Signature attribute, including Type, ID, Length
and authenticator. In calculating the End-to-End-Signature, the
authenticator should be considered to be filled with zeroes, and
the End-to-End-Signature string should be considered to be six-
teen octets of zero.
The portion of the RADIUS packet after the End-to-End-Signature
attribute is not included in the calculation of the MAC. This
makes it possible for a proxy to add, modify, or delete
attributes placed after the End-to-End-Signature attribute. As a
result, attributes placed prior to the End-to-End-Signature
attribute can be considered "protected" and those placed after
the attribute can be considered to be "unprotected." Note that
in order for the End-to-End-Signature to be verified, the proxy
MUST maintain attribute order.
6.3. Hidden
Description
The purpose of the Hidden attribute is to make possible end-to-end
encryption of individual attributes. This would make it possible
for attributes such as User-Password or Tunnel-Password to be sent
securely between a RADIUS client and a server, without risk of com-
promise by an untrusted proxy.
A summary of the Hidden attribute is shown below. The fields are
transmitted from left to right.
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
? for Hidden
Length
>=4
String
The String field includes the encapsulated ciphertext of the
attribute which is to be hidden end-to-end. The hidden attribute
is encrypted using a key and encryption algorithm which had pre-
viously been established between the two endstations. Note that
Calhoun & Aboba [Page 5]
INTERNET-DRAFT 20 July 1998
due to the 253 octet limitation on the size of RADIUS
attributes, the encapsulated attribute may be a maximum of 251
octets in length.
7. Table of Attributes
The following table provides a guide to which attributes may be found
in which kind of packets.
Request Accept Reject Challenge # Attribute
0-1 0-1 0-1 0-1 ? End-to-End-Signature
0+ 0+ 0 0+ ? Hidden
0-1 0-1 0-1 0-1 ? SPI
8. Security issues
The following security threats have been identified in roaming sys-
tems:
Rogue proxies
Theft of passwords
Theft of accounting data
Replay attacks
Connection hijacking
Fraudulent accounting
8.1. Rogue proxies
In conventional ISP application, the NAS, proxy, and home server exist
within a single administrative entity. As a result, the proxy may be
considered a trusted component.
However, in a roaming system implemented with proxy chaining, the NAS,
proxies, and home server may be managed by different administrative
entities. Through the use of shared secrets it is possible for proxies
operating in different domains to establish a trust relationship. How-
ever, if packets are only authenticated on a hop-by-hop basis, then
untrusted proxies are capable of perpetrating a number of man-in-the-
middle attacks.
These attacks typically involve the editing of attributes, or the mod-
ification or insertion of messages, such as the substitution of an
Access-Accept for an Access-Reject. For example, a proxy may modify
an Access-Accept sent by the home server so as to lessen the security
obtained by the client. For example, EAP attributes might be removed
or modified so as to cause a client to authenticate with EAP MD5 or
PAP, instead of a stronger authentication method. Alternatively, tun-
nel attributes might be removed or modified so as to remove encryp-
tion, redirect the tunnel to a rogue tunnel server, or otherwise
lessen the security provided to the client.
Calhoun & Aboba [Page 6]
INTERNET-DRAFT 20 July 1998
Through implementation of the End-to-End-Signature attribute, it is
possible to detect unauthorized addition, deletion, or modification of
protected attributes. Note that it is still possible for a rogue proxy
to add, delete, or modify unprotected attributes.
While a proxy MUST NOT send an Access-Accept to the NAS after receiv-
ing an Access-Reject from the home server, a proxy MAY send an Access-
Reject to the NAS after receiving an Access-Accept from the home
server. Note that in the latter case, a Security-Parameter-Index
attribute should be used denoting the security association between the
proxy and the NAS, rather than that between the home server and the
NAS, since the proxy has originated the packet. This will allow the
NAS to verify the End-to-End-Signature attribute within the packet,
and decide whether to silently discard the packet. As noted earlier,
an Access-Accept originated by a proxy MUST be silently discarded by
the NAS, even if the End-to-End-Signature attribute can be verified.
The determination of whether end-to-end security is to be used in a
conversation is made using out-of-band mechanisms. Typically this is
based either on static configuration or on the outcome of a key
exchange conversation between the two endpoints. However, once it is
determined that the end systems wish to use end-to-end security, all
packets sent MUST include an End-to-End-Signature attribute and pack-
ets received without an End-to-End-Signature attribute MUST be
silently discarded. Note that policy determination using an out-of-
band mechanism rather than a proxied conversation limits the ability
of a rogue proxy to interfere with the security negotiation between
the two end systems.
8.2. Theft of passwords or keys
Unless the Hidden attribute is used, where clients authenticate using
PAP, or where the Tunnel-Password attribute is included with the
Access-Accept, each proxy along the path between the local NAS and the
home server will have access to the cleartext password or key. In many
circumstances, this represents an unacceptable security risk. As a
result, the Hidden attribute SHOULD be used to provide end-to-end con-
fidentiality for User-Password or Tunnel-Password attributes.
8.3. Integrity and confidentiality of accounting data
Typically in roaming systems, accounting packets are provided to all
the participants along the roaming relationship path, in order to
allow them to audit subsequent invoices. In order to prevent modifica-
tion of accounting packets by untrusted proxies, the End-to-End-Signa-
ture attribute MAY be used. If it is desired that accounting data be
kept confidential from a proxy, the Hidden attribute MAY be used. If
the objective is to prevent snooping of accounting data on the wire,
then IPSEC ESP MAY be used.
Calhoun & Aboba [Page 7]
INTERNET-DRAFT 20 July 1998
8.4. Replay attacks
In this attack, a man in the middle or rogue proxy collects CHAP-Chal-
lenge and CHAP-Response attributes, and later replays them. If this
attack is performed in collaboration with an unscrupulous ISP, it can
be used to subsequently submit fraudulent accounting records to the
accounting agent for payment. The system performing the replay need
not necessarily be the one that initially captured the CHAP Chal-
lenge/Response pair.
While such an attack has always been possible, without roaming the
threat is restricted to proxies operating in the home server's domain.
With roaming, such an attack can be mounted by any proxy capable of
reaching the home server.
In order to protect against replay attacks, CHAP-Challenge and CHAP-
Response attributes MAY be protected using the Hidden attribute. CHAP
replay attacks can also be defeated by means of an end-to-end chal-
lenge-response exchange. For example, if the home server returns an
Access-Challenge packet containing a CHAP-Challenge attribute and
maintains state with respect to outstanding challenges, replay attacks
cannot succeed.
However, it should also be noted that end-to-end challenges (as prac-
ticed within the EAP MD5 authentication method, or in the CHAP-Chal-
lenge method described above) are also subject to attacks by rogue
proxies. In such an attack a proxy substitutes a static challenge for
the challenge sent by the home server, and on receiving the response,
checks it against a databases of hashes applied against a dictionary.
This attack may be prevented through use of the End-to-End-Signature
attribute.
8.5. Connection hijacking
In this form of attack, the attacker attempts to inject packets into
the conversation between the NAS and the home server. RADIUS as
described in [3] is vulnerable to such attacks since only Access-Reply
and Access-Challenge packets are authenticated. This attack may be
defeated via use of an End-to-End-Signature attribute.
8.6. Fraudulent accounting
In this form of attack, a local proxy transmits fraudulent accounting
packets or session records in an effort to collect fees to which they
are not entitled. This includes submission of packets or session
records for non-existent sessions, or submission of exaggerated ses-
sion times for actual sessions.
Such behavior will only be easily detectable in the event that roaming
users are making use of voluntary or compulsory tunneling, in which
case the tunnel server will generate its own accounting record, which
may be compared to that generated by the local ISP. However, tunneling
Calhoun & Aboba [Page 8]
INTERNET-DRAFT 20 July 1998
is expected to represent only a small percentage of roaming use.
In order to detect submisson of fraudulent accounting packets or ses-
sion records, the the accounting gateway SHOULD send copies of session
records to all parties with a financial interest in the session. Par-
ties receiving copies of these session records SHOULD reconcile them
with logs of proxied authentications.
In order to make it easier to match authentication logs with account-
ing records, home servers involved in roaming SHOULD include a Class
attribute in the Access-Accept. The Class attribute should uniquely
identify a session, so as to allow an authentication log entry to be
matched with a corresponding accounting log.
In order to be able to match accounting logs with logs of proxied
authentications, accounting agents SHOULD require that they act as an
authentication proxy for all sessions for which an accounting record
will subsequently be submitted.
9. Acknowledgments
Thanks to Glen Zorn of Microsoft for useful discussions of this prob-
lem space.
10. References
[1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming
Implementations." RFC 2194, Microsoft, Aimnet, i-Pass Alliance, Asi-
ainfo, Merit, September 1997.
[2] B. Aboba, G. Zorn. "Roaming Requirements." Internet-Draft (work
in progress) draft-ietf-roamops-romreq-09.txt, Microsoft, April 1998.
[3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit,
Daydreamer, April 1997.
[4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April
1997.
[5] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC
1321, MIT Laboratory for Computer Science, RSA Data Security Inc.,
April 1992.
[6] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication," Internet Draft (work in progress), draft-
ietf-ipsec-hmac-md5-01.txt, August 1996.
[7] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, Harvard University, March, 1997.
[8] B. Aboba, J.R. Vollbrecht, "Proxy Chaining and Policy
Calhoun & Aboba [Page 9]
INTERNET-DRAFT 20 July 1998
Implementation in Roaming," Internet Draft (work in progress), draft-
ietf-roamops-auth-05.txt, Microsoft, MERIT, July 1998.
11. Authors' Addresses
Pat R. Calhoun
Technology Development
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, CA 94025
Phone: 650-786-7733
Fax: 650-786-6445
EMail: pcalhoun@eng.sun.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-936-6605
EMail: bernarda@microsoft.com
Calhoun & Aboba [Page 10]