[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-saag
Subject:    Re: [saag] Help
From:       Jari Arkko <jari.arkko () piuha ! net>
Date:       2005-12-28 10:38:25
Message-ID: 43B26B21.6070507 () piuha ! net
[Download RAW message or body]

Hi,

> I have a simple question about authentication.If you could spend your
> time to read my email,I would appreciate you much.If this letter
> disturbed you, I'll appologize for that.

No problem. Feel free to ask.

> My question is about RADIUS(Remote Authentication Dial In User
> Service).I have read the RFC2865,and RFC2138.In these protocols, the
> RADIUS are in Client/Server Model.And there are Client,RADIUS server
> and proxy client.Now,my question is when there are messages transfered
> between proxy client and RADIUS server or between proxy clients,how to
> ensure the security of these messages?Is there any shared keys in the
> RADIUS server and proxy clients.And the messages are encrypted by
> these keys.And if so,how could these keys produced, and what's the
> lifetime of these keys and how to refresh these keys?Or is there any
> other methods to ensure the message transfered between proxy clients
> and between proxy client and RADIUS server?If the method is complex
> and hard to explain in a few words,could you please tell me where I
> can find the documents or protocols about these aspects?

RADIUS communications are typically protected with a shared secret, applied
in a hop-by-hop fashion. That is, the NAS and a proxy RADIUS server share
a secret and then there's another shared secret between the proxy RADIUS
server
and the home RADIUS server. Such keys are manually configured and typically
remain in effect until manually reconfigured. The actual protection on a
RADIUS packet is fairly weak, its based on MD5 (not even with HMAC) and
mostly only for integrity, not for confidentiality. See details from RFC
2865 Section 3.

It is also possible to employ an outer layer of protection on RADIUS
through IPsec. The details are in RFC 3579, Section 4.2, but as far
as I know this isn't very widely used in RADIUS deployments. This will
provide key lifetimes, key refresh, algorithm negotiation, etc. The
protection is hop-by-hop, i.e., the SAs terminate in the proxy server.

The other IETF AAA protocol, Diameter, uses only "outer layer
protection", which in most cases in Diameter is TLS. See RFC 3588
for the details. This provides roughly the same properties as
the IPsec protection as well as offering application-level
granularity in the configuration of policies and trusted peers.

There has also been past work in end-to-end protection of
communication through AAA proxies, but this work was abandoned
due to lack of interest, and (I suspect) mismatch with business
policies and practises that require both examination and even
modification of some of the authorization parameters passed
in these transactions. However, recent work such as RFC 4005
recommends a different approach to securing AAA via proxies, by
allowing a "redirect" to take place so that the sensitive information
can bypass the proxies. But it is unclear again whether this
mode is being employed in practical deployments.

Finally, there has been some past work on providing better automation
for setting up the shared secrets. See draft-moskowitz-shared-secret-
provprotocol-01.txt, for instance.

The RADEXT WG mailing may be a good place for further discussions.

Hope this helps,

--Jari

_______________________________________________
saag mailing list
saag@mit.edu
http://jis.mit.edu/mailman/listinfo/saag
[prev in list] [next in list] [prev in thread] [next in thread]