Subject: [proxies] New draft: draft-hoeper-proxythreat-01.txt

From: Katrin Hoeper <[email-masked]>
Date: Tue, 04 Nov 2008 09:27:07 -0500

Hey,

A new version of the "Threat Model for Networks Employing AAA 
Proxies" is available at 
http://tools.ietf.org/html/draft-hoeper-proxythreat-01.

Stefan Winter joined as a co-author and the 01-draft contains his 
comments on the first draft.

----------
Katrin Hoeper
Computer Security Division
National Institute of Standards and Technology (NIST)
100 Bureau Dr. Mail stop: 8930
Gaithersburg, MD 20899
(301) 975 - 4024
_______________________________________________
Proxies mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/proxies

---

From: Katrin Hoeper <[email-masked]>
Date: Tue, 04 Nov 2008 10:58:06 -0500

Please post your comments on the -00 draft that have not been 
addressed in -01 as well as your comments on the -01 draft to the list.

If you have no time to write up your comments, you can find me at the 
IETF 73 meeting in Minneapolis.
Just send me an email and we can arrange a meeting.

Katrin

----------
Katrin Hoeper

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 5 Nov 2008 00:56:27 -0800

Overall comment:  

Discussion of AAA proxy security issues has a long history within the IETF, starting in 1996
with the IESG review of RFC 2607, which spawned the development of RFC 4962, the 
AAA requirements documents, and threat model and security analysis included within RFC 5247. 

As with NAT, AAA proxies became widely entrenched before their implications were
fully understood, and in addition, they offered the solution to a wide range of
real or perceived problems, as discussed in RFC 2607.   

Given this, progress on the proxy problem has experienced some of the same
issues that have been encountered in developing "NATless" infrastructures within
IPv6.  While in theory alternatives are possible, in practice there are many
operational details that would need to be solved before they can be deployed. 

Teasing out all the potential benefits of proxies, and evaluating the extent
to which deployable alternatives are available has proven to be a daunting
task.   For example, the key management issues identified in RFC 2607
have been attacked via a variety of PKI approaches, which themselves
have encountered deployment issues, influencing the perceived practicality
of proposals such as Diameter CMS and Redirect.  

However, at the same time, some of the operational issues with proxies
(such as increased packet loss and latency) have also come to be better
appreciated, motivating new approaches to solutions within organizations
such as EDUROAM.  As a result, it would appear to me that operational
issues, not security, provide both the major impediments to and motivations 
for progress. 

While the focus of this document is threat analysis, it would seem important
to address some of those operational concerns, given their critical influence
on deployment.  Otherwise we risk developing a scism between the 
Security and O&M Areas in addressing these concerns. 

Specific Comments

   The introduction of proxies can change the security model of a
   network as well as of the implemented protocols. As a consequence,
   AAA proxies may introduce new security vulnerabilities. However,
   currently the role of AAA proxies in networks and all their security
   implications are not considered in many existing RFCs and Internet
   drafts. The relationship with RFC 4962 [1] is the most glaring aspect
   of the problem, but the progress of numerous drafts in a number of
   working groups is affected by the so-called "proxy problem".
   Recently, there have been attempts to reconcile the widespread
   deployment of AAA proxies with the security requirements of
   individual Internet protocols or protocol extensions.

The security vulnerabilities introduced by AAA proxies are not "new";
the RFC 2607 security analysis was initially requested by the IESG a 
decade ago.  In order to address the issues raised by the RFC 2607
threat analysis, support for end-to-end security was made a 
requirement for the development of a new AAA protocol. 
RFC 4962 was developed in part to formalize that requirement,
and RFC 5247 was added to the EAP WG charter in order to provide
an analysis of the degree to which existing EAP/AAA implementations
complied with those requirements. 

In order to satisfy the requirements that eventually were codified
in RFC 4962, the AAA WG developed multiple proposals for
end-to-end transport of attributes through proxies; these included
CMS, Kerberos, and Redirect proposals.  Of these, the AAA WG eventually
settled on Diameter Redirect, and this proposal was included within
RFC 3588.  

Given all of this, AAA proxies have long been an area of focus within
the IETF, encompassing many man-years of work which have resulted in
more than a hundred pages of RFCs and Internet-Drafts relating to the
issue as well as many, many discussions and postings on the subject. 

Therefore to say that the implications are "not considered" seems
odd, given the amount of time that has been spent on this. 

   Doubts exist whether current security claims stated in RFCs and
   Internet Drafts are still valid for implementations with proxies.

"Doubts" is perhaps too weak a word -- RFC 5247 shows that many
of the fundamental security requirements can no longer be met
where proxies are present. 

   Hence, providers of networks with proxies that rely on such security
   claims may have unknowingly introduced new vulnerabilities to their
   systems that have not been covered in the respective protocol
   specifications. For the same reasons, users of such systems may be
   unknowingly exposed to attacks.

Not sure that the term "unknowing" is appropriate here.  Given the 
volume of work, it would be quite hard for providers to plead ignorance.
Rather, the issue is more likely to be the difficulty of operating
and managing a network that addresses the problems. 

   Concluding, the proxy problem may affect existing and future
   implementations of Internet protocols whose specifications neglected
   proxies in their security considerations. If security issues
   introduced by proxies are not identified and addressed, future
   protocol specifications will suffer from the same problems.

Proxies have become a fundamental aspect of the architecture of a
number of IETF protocols, including SMTP, SIP and AAA.  In each
case, implementers and deployers of those protocols are painfully
aware of the problems that they cause.  Also, in each case a number
of proposals have been made (such as domain certificates) to address
operational issues.  So I don't think you can say that proxies
have been neglected in the security considerations.

Section 1.1

   This document solely identifies security-related issues introduced by
   AAA proxies and their severity but neither provides solutions to
   address these problems nor discusses non-security related issues
   (such as routing, performance, etc.). Furthermore, this document does
   not consider AAA proxies that are configured to solely serve as a re-
   direct (as supported by Diameter), because such proxies do not need
   to gain access to attributes and/or keying material.

As noted earlier, operational issues have proven to be a very difficult
challenge.  If you ignore these, I think you will miss the crux of the
problem. 

Section 2

  Unlike some other network entities that simply forward packets in the
   network, AAA proxies are designed to have additional capabilities and
   properties such that the AAA protocols executed through AAA proxies
   may have the following features:

   o  AAA proxies are able to modify and/or delete AAA attributes

   o  AAA proxies share pairwise AAA keys with the AAA server and/or
      other AAA proxies;

   o  AAA proxies and NAS cannot be distinguished by AAA server;

   o  AAA proxies and AAA server cannot be distinguished by NAS;

   o  AAA proxy chains cannot be distinguished from single proxies by
      neither NAS nor AAA server.

Each of the above statements are not always true:

a.  The Diameter CMS, Redirect  and Kerberos proposals limited the 
ability of AAA proxies to modify attributes.  

b. Security schemes such as Diameter or RADSEC do not rely on 
pairwise AAA keys, but are based on certificates. 

c. Properly configured AAA servers *can* distinguish between AAA clients. 

d. Properly configured NASes *can* distinguish between AAA servers and proxies.

e. Some proposals *do* support distinguishing of proxy chains from single proxies
(e.g. RADIUS/Kerberos, Route Record functionality). 

Section 3

3. Related Work

   [Editor's note: what other references should be mentioned here?]

I'd look at RFC 5247, which discusses the EAP security model and the
effects of proxies (and AAA mis-configuration) in some detail.   There
are also the Diameter CMS and RADIUS/Kerberos proposals, the AAA
Requirements Documents, and discussions of proxy security and deployment
in the RADIUS, AAA, RADEXT, DIME and SIP WGs. 

Section 4.1

   In enterprise networks or other local networks with a single
   administrative domain, AAA proxies are used to enable easy and
   scalable network access in large networks.

Given the prevalence of enterprise customer arrangements with 
access wholesalers and aggregators, many enterprise deployments
do in fact support inter-domain usage.  However, in those
deployments it's probably accurate to say that the enterprise
trusts the wholesaler/aggregator infrastructure. 

   Hierarchical proxy routing can
   further simplify key management, as has been pointed out in RFC 2607.

The Terena/EDUROAM experience is probably worth pointing out here, since
they are both using certificates (rather than symmetric keys), as well
as encountering issues with latency (leading to the desire for reduced
chain length).

---

From: Stefan Winter <[email-masked]>
Date: Fri, 14 Nov 2008 16:01:51 +0100

Hi Bernard,

thanks a lot for this thorough review! I won't be able to answer you in
all detail before leaving to MSP, but a few general remarks:

as you may have seen, I've recently been invited as a co-author of this
document. I was starting with the precondition that this document is
strictly dealing with the *threats* which are introduced by proxies. I'm
in line with your comments below though that it might make more sense to
broaden the scope to include usage considerations about proxies.
renaming it to, say, "AAA Proxy Operational Considerations" or so. If
such a broadening of scope is seen as a good idea, I would certainly
also be available to include the operational experience of the eduroam
community, where I'm somewhat involved. I'm sure we will have one or
another opportunity to discuss the course of the document in Minneapolis.

Greetings,

Stefan Winter

Bernard Aboba schrieb:
>    drafts. The relationship with RFC 4962 <http://tools.ietf.org/html/rfc4962> [1 <http://tools.ietf.org/html/draft-hoeper-proxythreat-01#ref-1>] is the most glaring aspect
>    further simplify key management, as has been pointed out in RFC 2607 <http://tools.ietf.org/html/rfc2607>.
>
> ------------------------------------------------------------------------
>

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Katrin Hoeper <[email-masked]>
Date: Fri, 14 Nov 2008 10:54:32 -0500

Bernard,

thank you for your comments.

As I am working in the security area, my and my 
group's main interest are naturally in securing systems.
I agree that operational and management issues 
are also of great importance but given my 
background, I cannot write such a document.

If there should be an interest in extending the 
scope to cover both security and O&M issues,  I 
am absolutely not against it, as long as there 
are co-authors with O&M background taking on this task.

It seems that Stefan is interested, but I would 
like to know from the rest of the list how they 
feel about this extension of the scope.
And even more importantly, if they think this 
would be a great idea, if they are interested to 
actively contribute to the draft by becoming a co-author.

I really hope we and other interested folks can 
meet in Minneapolis to discuss this.

Katrin

At 10:01 AM 11/14/2008, Stefan Winter wrote:
> >    drafts. The relationship with RFC 4962 
> <http://tools.ietf.org/html/rfc4962> [1 
> <http://tools.ietf.org/html/draft-hoeper-proxythreat-01#ref-1>] 
> is the most glaring aspect
> > d. Properly configured NASes *can* 
> distinguish between AAA servers and proxies.
> >
> >    further simplify key management, as has 
> been pointed out in RFC 2607 <http://tools.ietf.org/html/rfc2607>.
> >

----------
Katrin Hoeper

---

From: Klaas Wierenga <[email-masked]>
Date: Sat, 15 Nov 2008 13:16:34 +0100

Hi,

I am not very much in favor of mixing security considerations with
operational considerations of proxies. It is my understanding that these
are of a different nature. I would prefer to work from the assumption in
this document that we stay out of any debate about whether proxies are a
good or a bad thing but rather take it as a given and analyse the
security and privacy threats that result.

An operational considerations document would be a welcome separate
document, but let's not mix these two. In a way the latter document to
some extent will explain how the security threats can be overcome (in
addition to other operational considerations).

Or to put in yet another way, I believe the former document is more of a
theorteical exercise whereas the second is dealing with the practical
impact of this exercise.

Klaas

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 15 Nov 2008 12:51:43 -0800

> I am not very much in favor of mixing security considerations with> operational considerations of proxies. It is my understanding that these> are of a different nature. I would prefer to work from the assumption in> this document that we stay out of any debate about whether proxies are a> good or a bad thing but rather take it as a given and analyse the> security and privacy threats that result.
 
The point is that the IETF has been working on this problem for a long time
already.   Multiple areas within the IETF have had major issues with proxies,
and in toto, there are probably several hundred pages of threat analyses and
proposals (some implemented, some not).  Many of the issues encountered
by different areas are very similar (e.g. the discussion relating to SRTP
keying in SDP is not very different from the discussion of key transport
in AAA).  
 
Given this extensive body of work, the question is how to move forward.  
One of the things we learned from the NAT debate was that it was
critical to develop a detailed understanding of how NATs deployed in the
field actually behaved.  In many cases the actual behavior was
more complex and variable that we had believed originally.  
 
Similarly, I believe that understanding how proxies are actually deployed
and used is critical.  For example, at present inter-domain 
key transport via proxies is very rarely deployed (EDUROAM is the only
major deployment I am aware of).  This is because 802.11i has not caught
on in hospitality, hotspots or carriers, where web portals are overwhelmingly
popular.  In enterprise, where 802.11i has caught on, but there is not much
interest in inter-domain key transport, probably because most of the local
access networks don't support IEEE 802.11i. 
 
Aside from IEEE 802.11, the major wireless technology that has contemplated
use of EAP keying along with AAA roaming is WiMAX.   However, WMF v1.0 roaming
support is weak (there is no mandatory-to-implement user authentication mechanism),
so that most of the initial deployments don't support roaming.  In addition, wholesaling
is also not well supported (AAA servers need to obtain a certificate from the WMF,
at considerable cost).  As a result, there is not much chance that inter-domain 
key transport will be deployed for WiMAX in the near future. 
 
Some similar observations can be made relating to the deployment of inter-domain
SIP with SRTP.  Neither SIP inter-domain use nor SRTP support are common today,
and the intersection of the two is virtually non-existent.   So while end-to-end
security might seem like a useful goal, in practice there is not much movement
toward that in evidence.  It's barely possible to even purchase a handset with
minimal SRTP (e.g. RFC 3711) support today. 
 
My takeaway from all this is that real world deployments appear to have a
very low complexity tolerance.  Even technologies which are frequently
assumed to be well established (e.g. EAP, 802.1X) frequently exceed that 
tolerance level.
 > An operational considerations document would be a welcome separate> document, but let's not mix these two. In a way the latter document to> some extent will explain how the security threats can be overcome (in> addition to other operational considerations).
 
The IETF has already produced lots of documents relating to "solutions"
to the proxy security problem.  The AAA WG alone spent 5 years on this,
producing three different proposals, two of which have actually been
implemented (e.g. Diameter Redirect and AAA/Kerberos integration). 
 
So neither a problem analysis nor proposed solutions are new.

---

From: Klaas Wierenga <[email-masked]>
Date: Sun, 16 Nov 2008 10:18:43 +0100

Bernard Aboba wrote:

Bernard,

Fair points, but aren't you than essentially saying "forget about the 
threats and write *only* a deployment draft"?

Klaas

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 16 Nov 2008 06:42:47 -0800

> threats and write *only* a deployment draft"?

The document doesn't cite some existing threat model assessments,
including RFC 5247 which is standards track and was chartered for
this purpose.  So I'd say that a new threat model document (if it
is needed) should focus on what is missing or what has 
changed with respect to those prior assessments.

One thing that has changed is RADSEC.  RADSEC challenges may of the 
assumptions that have been made relating to RADIUS, such as:

         RADIUS clients and servers cannot support certificates
         RADIUS cannot support confidentiality
         RADIUS requires a "trapezoid" model similar to SIP
         RADIUS clients cannot handle DNS lookups
         Proxy-avoidance technologies such as Diameter "redirect" cannot be deployed
         Large scale roaming between many domains is very difficult to set up
         
Once these assumptions become invalid, many of the security threats/issues also
disappear, and new ones may appear in their place.  In particular, given that
EDUROAM is virtually the only large scale deployed instance of inter-domain key 
transport, it probably makes sense to focus on it, rather than analyzing the 
security risks of other (nonexistent) deployments such as WiMAX. 

For example, if we start with the analysis of the operational benefits

of proxies described in RFC 2607, we find that several of the benefits
don't exist with RADSEC:
1.   Scalability improvement
2,   Authentication forwarding
3.   Capabilities adjustment
4.   Policy implementation
5.   Accounting reliability improvement
6.   Atomic operation

Of these benefits, at least #1 and #2 is no longer 
required with RADSEC using certificates.  Do benefits
#3, 4, 5 or 6 occur in a network such as EDUROAM?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 17 Nov 2008 13:44:08 +0100

Bernard Aboba wrote:
> on in hospitality, hotspots or carriers, where web portals are
> overwhelmingly popular.

  There are, as always, discussions about rolling out world-wide roaming
for 802.1X.  Trials are occurring now, but I think widespread deployment
is 2-3 years out.

> assumed to be well established (e.g. EAP, 802.1X) frequently exceed that

  Even standard RADIUS has significant complexities when used for
world-wide roaming.  The people building the equipment often don't
understand the specs (and therefore don't follow them), the people
deploying the equipment often don't understand networking, and the
people managing the businesses often don't understand their market.

  The result is a world-wide network which is composed of the lowest
common denominator.  Usernames/passwords go one way, ACKs/NAKs go the
other, and generally you see an accounting Start.

  I think there's a need for a document that covers *more* than the bits
& bytes in the protocols.  e.g. Both recommended and not recommended
network design, practices, etc.  Such a document could be used as a
reference for global roaming implementations.  It could also
significantly increase network reliability, and shorten deployment
times, by educating the people who build and maintain those networks.

  Alan DeKok.