[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Sat, 13 Nov 1999, Bernard Aboba wrote:
> > In short, one of the things not spelled out in the charter is that when we
> > say 'legacy user authentication', we are really talking about people's AAA
> > infrastructure. At least I believe so. Anything that does not let
> > reuse their eisting radius databases, will simply not work.
> I think the point is that the entire architecture for IPSRA needs to be
> spelled out. I am not particularly convinced that AAA integration is
> either necessary or desirable for IPSRA, but if that is an implicit
> assumption driving the requirements, then it needs to be spelled out
> explicitly and addressed in the architecture.
I was under the impression that the drive to use L2TP/IPSEC was precisely to
reuse the existing PPP/AAA infrastructure that customers have.
> 2. Use of RFC 2138 would expose weak-link vulnerabilities, since this only
> supports shared-secret security with no confidentiality and is vulnerable
> to man in the middle attacks. See RFC 2607 for a discussion of the gory
> details. So you'll need to do some very careful thinking about security
> requirements before going down that road.
I punted on those for two reasons: Radius is not the only AAA protocol out
there (there's tacacs+, for instance, and possibly diameter, or whatever the
AAA group comes up with next. The second reason is that I can (in some
limited simplistic architectures) protect the radius traffic with ipsec in
I don't think we'll get around this, but maybe my view is too limited.
> 2. Before concluding that RFC 2138 authorization is needed or useful it
> would be nice to understand what the requirements are and why these cannot
> be met through conventional IPSEC security policy. Requirements definition
> is useful because it isn't at all clear to me that the PPP-oriented
> authorizations available in RFC 2138 make any sense to an IPSRA server.
> For example, what do you do with AppleTalk attributes? Session-Time?
Depends: When using PPP/L2TP, you use the appletalk attributes when appletalk
comes up, and ignore them otherwise.
In the other proposals (all of which are at phase1 or phase1.5), I'd argue
that you only use the IP attributes, since currently all we have is ipsec,
which, by definition, is IP. Appletalk attributes would simply be ignored.
Just as we do now in PPP, all attributes get scrutinized as to when they are
usefull. I don't see why this would change here. If session-time or appletalk
attributes are not relevant, they are ignored.
But your points are well taken. Where's the requirements?! Should I post a
bulleted list of the ones I consider relevant, and people can start sniping
at them or adding on to them?
Jan Vilhuber vilhuber@xxxxxxxxx
Cisco Systems, San Jose (408) 527-0847