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

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

   The introducti=
on of proxies can change the security model of a
   network as well as o=
f the implemented protocols. As a consequence=2C
   AAA proxies may intr=
oduce new security vulnerabilities. However=2C
   currently the role of =
AAA proxies in networks and all their security
   implications are not c=
onsidered in many existing RFCs and Internet
   drafts. The relationship=
 with RFC 4962 [1] is the most glaring aspect
   of the pr=
oblem=2C but the progress of numerous drafts in a number of
   working g=
roups is affected by the so-called "proxy problem".
   Recently=2C there=
 have been attempts to reconcile the widespread
   deployment of AAA pro=
xies with the security requirements of
   individual Internet protocols =
or protocol extensions.

The security vulnerabilities introduced by A=
AA proxies are not "new"=3B
the RFC 2607 security analysis was initially=
 requested by the IESG a 
decade ago.  In order to address the issues ra=
ised by the RFC 2607
threat analysis=2C support for end-to-end security =
was made a 
requirement for the development of a new AAA protocol. 
R=
FC 4962 was developed in part to formalize that requirement=2C
and RFC 5=
247 was added to the EAP WG charter in order to provide
an analysis of t=
he degree to which existing EAP/AAA implementations
complied with those =
requirements. 

In order to satisfy the requirements that eventually =
were codified
in RFC 4962=2C the AAA WG developed multiple proposals for=

end-to-end transport of attributes through proxies=3B these includedCMS=2C Kerberos=2C and Redirect proposals.  Of these=2C the AAA WG eventua=
lly
settled on Diameter Redirect=2C and this proposal was included withi=
n
RFC 3588.  

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

Therefore to say that the implications are "not co=
nsidered" seems
odd=2C given the amount of time that has been spent on t=
his. 

   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 manyof the fundamental security requirements can no longer be met
where pro=
xies are present. 

   Hence=2C providers of networks with proxies th=
at rely on such security
   claims may have unknowingly introduced new v=
ulnerabilities to their
   systems that have not been covered in the res=
pective protocol
   specifications. For the same reasons=2C users of suc=
h systems may be
   unknowingly exposed to attacks.

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

   Concluding=2C the proxy probl=
em may affect existing and future
   implementations of Internet protoco=
ls whose specifications neglected
   proxies in their security considera=
tions. If security issues
   introduced by proxies are not identified an=
d addressed=2C future
   protocol specifications will suffer from the sa=
me problems.

Proxies have become a fundamental aspect of the archite=
cture of a
number of IETF protocols=2C including SMTP=2C SIP and AAA.  I=
n each
case=2C implementers and deployers of those protocols are painful=
ly
aware of the problems that they cause.  Also=2C in each case a number=

of proposals have been made (such as domain certificates) to addressoperational issues.  So I don't think you can say that proxies
have bee=
n neglected in the security considerations.

Section 1.1

   Th=
is document solely identifies security-related issues introduced by
   A=
AA proxies and their severity but neither provides solutions to
   addre=
ss these problems nor discusses non-security related issues
   (such as =
routing=2C performance=2C etc.). Furthermore=2C this document does
   no=
t consider AAA proxies that are configured to solely serve as a re-
   d=
irect (as supported by Diameter)=2C because such proxies do not need
   =
to gain access to attributes and/or keying material.

As noted earlie=
r=2C operational issues have proven to be a very difficult
challenge.  I=
f you ignore these=2C I think you will miss the crux of the
problem. 
Section 2

  Unlike some other network entities that simply forw=
ard packets in the
   network=2C AAA proxies are designed to have additi=
onal capabilities and
   properties such that the AAA protocols executed=
 through AAA proxies
   may have the following features:

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

   o  AAA =
proxies share pairwise AAA keys with the AAA server and/or
      other A=
AA proxies=3B

   o  AAA proxies and NAS cannot be distinguished by A=
AA server=3B

   o  AAA proxies and AAA server cannot be distinguishe=
d by NAS=3B

   o  AAA proxy chains cannot be distinguished from sing=
le proxies by
      neither NAS nor AAA server.

Each of the above=
 statements are not always true:

a.  The Diameter CMS=2C Redirect  a=
nd Kerberos proposals limited the 
ability of AAA proxies to modify attr=
ibutes.  

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

c. Prop=
erly configured AAA servers *can* distinguish between AAA clients. 

=
d. Properly configured NASes *can* distinguish between AAA servers and prox=
ies.

e. Some proposals *do* support distinguishing of proxy chains f=
rom single proxies
(e.g. RADIUS/Kerberos=2C Route Record functionality).=

Section 3

3. Related Work

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

I'd look at RFC 5247=2C which discusses =
the EAP security model and the
effects of proxies (and AAA mis-configura=
tion) in some detail.   There
are also the Diameter CMS and RADIUS/Kerbe=
ros proposals=2C the AAA
Requirements Documents=2C and discussions of pr=
oxy security and deployment
in the RADIUS=2C AAA=2C RADEXT=2C DIME and S=
IP WGs. 

Section 4.1

   In enterprise networks or other local=
 networks with a single
   administrative domain=2C AAA proxies are used=
 to enable easy and
   scalable network access in large networks.
Given the prevalence of enterprise customer arrangements with 
access w=
holesalers and aggregators=2C many enterprise deployments
do in fact sup=
port inter-domain usage.  However=2C in those
deployments it's probably =
accurate to say that the enterprise
trusts the wholesaler/aggregator inf=
rastructure. 

   Hierarchical proxy routing can
   further simpli=
fy key management=2C as has been pointed out in RFC 2607.

The Terena/EDUROAM experience is p=
robably worth pointing out here=2C since
they are both using certificate=
s (rather than symmetric keys)=2C as well
as encountering issues with la=
tency (leading to the desire for reduced
chain length).  

1.   Scalability improvement
2=2C   Au=
thentication forwarding
3.   Capabilities adjustment
4.   Policy impl=
ementation
5.   Accounting reliability improvement
6.   Atomic operat=
ion

Of these benefits=2C at least #1 and #2 is no longer 
require=
d with RADSEC using certificates.  Do benefits
#3=2C 4=2C 5 or 6 occur i=
n a network such as EDUROAM?