Re: [proxies] Review of draft-hoeper-proxythreat-01.txt (Part 1)

[Katrin Hoeper <[e-mail]>]

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:
>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:
> > 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 
> <http://tools.ietf.org/html/rfc4962> [1 
> <http://tools.ietf.org/html/draft-hoeper-proxythreat-01#ref-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 <http://tools.ietf.org/html/rfc2607>.
> >
> > 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).
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Proxies mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/proxies
> >
>
>
>--
>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: [phone]
>Fax: [phone]


----------
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
[e-mail]
https://www.ietf.org/mailman/listinfo/proxies