[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on draft-gaonkar-radext-erp-attrs-00
Lakshminath Dondeti <mailto:ldondeti@qualcomm.com> allegedly scribbled
on Monday, July 16, 2007 10:22 PM:
> Glen,
>
> Many thanks for your note. I was somewhat familiar with the keyreq
> and keywrap drafts, although I haven't followed their progress in the
> IETF closely. I also haven't reviewed them before working on the ERP
> attributes draft; I should have.
>
> One of the goals of draft-gaonkar-radext-erp-attrs-00 is to piggyback
> the key request and response on the EAP authentication or the EAP
> reauthentication exchange. After some reading, I think we can use
> the techniques of keyreq and keywrap within new RADIUS attributes.
> So, for instance we can incorporate the Request and Response
> Authenticators of the keyreq draft (although I don't quite like the
> MD5 construction there and would propose to revise it)
The constructs were chosen to make the new messages look as much like
existing RADIUS messages as possible (not to minimize code changes
(which would take about 10 minutes) but to minimize whining from IETF
"experts" (that could go on for years ;-)).
> and the keying
> material and other attributes of the keywrap drafts. If that is
> something the WG might like, Kedar and I can work with the authors of
> keyreq and keywrap offline and revise the draft accordingly.
>
> Some notes inline:
>
> On 7/15/2007 3:05 PM, Glen Zorn (gwz) wrote:
>> I would like to note that there is pre-existing work in this area
>>
(_http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-07.txt_
>> ,
>>
_http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt_).
>> Be that as it may, however, it's difficult to understand what the
>> purpose of the Requesting Entity's Identity in the express
>> environment
>> that is implied by the draft (i.e., a request from a visited network
>> to a home network). If, as I assume (please correct me if my
>> assumption is incorrect), the requesting entity is a NAS it doesn't
>> seem reasonable to
>
> The requesting entity might be a DSRK server.
What is a "DSRK server"? Is it the same as a hokey server?
>
>> believe that the RADIUS server in a remote network would have any
>> knowledge of it, even less so in the case where the visited and home
>> networks are separated by one or more proxies & thus lack any direct
>> trust relationship. If this identity is meant to be used for key
>> binding purposes, I think that this is incredibly dangerous, imputing
>> trust as it does between the home RADIUS server and an entity of
>> which
>
> The DSRK server can provide its identity via the lower layer to the
> peer
One of the things that bothers me a lot about the proposals we're seeing
is the tendency to rely upon unspecified and possibly non-existent
"lower layer" mechanisms. I think that this is unnecessary.
> and via RADIUS protocol to the RADIUS server.
In the case where the DSRK server is separated from the home RADIUS
server by one or more proxies, why should the home server believe the
identity it receives?
> The peer can
> communicate the identity in an end-to-end protected manner to the
> server, thus forcing the DSRK server to present the same identity to
> the peer and the server.
I still have problems understanding the utility of this. Leaving aside
the "lying proxy" problem, let's take an example from real life: suppose
that someone introduces himself to a young woman as "Ted Bundy" and she
checks with a trusted friend who confirms this claimed identity. If
neither the young woman nor her friend knows that "Ted Bundy" is a
vicious serial killer, what good does this confirmation do? If you
assume that the DSRK server cannot be trusted (otherwise why force it to
do anything?), then why does the fact that it's not lying about its
_name_ magically make it trustworthy?
...
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>