Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt

>this was already fixed in 04 that i announced to the list a few weeks
>ago.   the terms conflicting 2486 are gone.

[BA] Good. If there is a need to update 2486 for some reason, this can be
accomplished within the RFC 2486bis effort.

>my draft doesn't use radius for service discovery.  the service type in
>the radius request that the pe makes is VPN-Login.  so the pe already
>knows what service to ask for.

[BA] My error, sorry.

Use of RADIUS for discovering VPN endpoints is OK, and is described
in RFC 2868.  It is not even necessary to know what type of VPN is
desired, since this is returned in the Access-Accept.

>what comes to the security issue, it is not at all unreasonable to
>assume that there exists a security relationship between pes of a
>provider and the radius servers of the same provider.  it is in the same
>category than assuming that there is a security association between pes
>and their snmp management system.

[BA] Preconfiguration may not necessarily be required but there
are some pitfalls.  For example, it possible for the RADIUS server to
return a Tunnel-Password attribute as indicated in RFC 2868.  However,
the security of that mechanism is somewhat suspect, so it would be
better if it was not necessary to use it.

>it is very common that radius requests have side effects.  any
>reasonable radius server on the market supports configuration of pre and
>post authentication hooks.  otherwise routine things like checking of
>simultaneous use would not be possible.

[BA] The point is that there should not be an expectation that existing
RADIUS servers can be implement this specification merely by making
changes to the RADIUS Dictionary.  That needs to be stated clearly.

It's also worth mentioning that most RADIUS Dictionaries only support
attributes of types defined in RFC 2865.  That means that Attribute
structures are typically only supported within the "String" type, and
inherent server support for that is limited.

The major problem with stateful application of RADIUS (such as
simultaneous usage checks) is the unreliability of RADIUS accounting traffic.  That
implies that the state on the RADIUS server can easily get out of sync,
and a mechanism needs to be provided to resynchronize.  In the case of
simultaneous usage checks, the accounting info is typically supplemented
by telnet-based access or a proprietary SNMP MIB.  The end result is that
stateful uses typically have implementation-dependent components,
and therefore don't interoperate well.

This could be addressed either by specifying the required transport
behavior or by providing an interoperable resynchronization mechanism.

>i don't see the use of Interim Accounting for failure detection a big
>protocol abuse.  that request is normally used to keep accounting
>information as accurate as possible in case the nas fails and is not
>able to send stop accounting request.  its use here is close to that
>purpose.

[BA] This is problematic because RADIUS Accounting retransmission behavior
is not specified -- and therefore the loss of an interim packet may not
indicate a "failure" at all -- but just ordinary packet loss.  In any
case, the proper behavior of a RADIUS client not receiving a Response is
to initiate failover.  So the packet may just have been sent to an
alternative RADIUS Accounting server and received there.

>thanks for the "joke".

[BA] RADIUS security problems are not a joke.  The security of RADIUS was
marginal at the time it was proposed, but by now it has become quite easy
to crack if the implementation or deployment configuration has even the
slightest weakness.  This includes known plaintext attacks similar to
those which can be carried out on WEP, dictionary attacks on the RADIUS
shared secret, and even brute force attacks on the (sub-standard) ciphers
used to hide attributes.

My advice is to consider the security weaknesses present in RFC 2868 and
include potential mitigating measures in the Security Considerations
section.  An example of such a section is available here:

http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-22.txt


>that would include some "concerns" regarding the draft, because the one
>i now replied to was empty of them.

[BA] Overall, I think that the draft has value and its purpose is
within the precedent established in RFC 2867-2868.  Given that RADIUS
already supports configuration of VPNs and VLANs, it is not much of a
stretch to see it being used for PPVPN configuration.

However, there are things that RADIUS implementations cannot be guaranteed
to do well, primarily because of the lack of a transport and failover
specification, and limitations in the original security design.

The question is whether potential implementors will be ok with the changes
that might be necessary to address these issues.  An example would be use
of IPsec to protect the RADIUS exchanges,  or the specification of
required retransmission behavior.

These changes will inevitably make the implementations more complex and
expensive -- but will also make them more reliable and secure.