Email lists > > [Mip4] RE: draft-ietf-mip4-radius-requirements-01.txt > [Mip4] RE: draft-ietf-mip4-radius-requirements-01.txt

[Mip4] RE: draft-ietf-mip4-radius-requirements-01.txt




This post if a part of  this thread

2007-04-13 12:08:37
RE: draft-ietf-mip4-radius-requirements-01.txt
Hi Alan, 

Once again, thanks for the reply.

Regarding intermediaries and Diameter redirect, there was
actually some text
explaining about Diameter redirect and the fact that it does
not exist in
RADIUS and given that we are not setting any requirements to
change that, I
removed all the text. Do you think I should add anything to
that effect in
the non-goals section or in the security section (as it was)
or nothing at
all, like I have right now?

R,

Madjid

-----Original Message-----
From: Alan DeKok [mailto:alandfreeradius.org] 
Sent: Thursday, April 12, 2007 5:54 PM
To: Madjid Nakhjiri
Cc: 'McCann Peter-A001034'; 'Mobile IPv4 Mailing List'; 'Avi
Lior';
'Chowdhury, Kuntal'; kleungcisco.com
Subject: Re: draft-ietf-mip4-radius-requirements-01.txt

Madjid Nakhjiri wrote:
> Except the effect on proxy, most of your comments
should be addressed. Let
> me consult with co-authors and come up with a text for
effect on proxies.
> My immediate response is the proxies MUST not be
affected either (same as
> servers).

  I agree.

>>   RFC 2686 Section 3.5 offers no protection against
MITM attacks,
>> where intermediate nodes proxy the request, but are
untrusted.  As
>> the earlier paragraph in this draft states, RADIUS
assumes that all
>> intermediaries are trusted.  Perhaps something else
is meant by this
>> text?    
>>
> Madjid>>I think MITM is over-emphasized, the
point in sending keys and
> sensitive material over multiple hops and as you say
not much can be done
> here. I did add Glen's keywrap doc as a reference, but
removed a lot of
text
> in the new write up (added your text to the
beginning):
> 
> "Security considerations
> 
>    This document defines no new requirements or
security mechanisms for
>    RADIUS.  As such, the existing RADIUS security
considerations
>    described previously apply, and no additional
security considerations
>    are added here.  For instance, the concern of using
AAA protocols
>    that use hop-by-hop security (Diameter/RADIUS) to
distribute keys is
>    nothing new.  In both Diameter and RADIUS the
assumption is that
>    intermediary nodes are trusted.

  Diameter supports redirects, which allows intermediate
nodes to be
bypassed.  (i.e. they may not be trusted)

  RADIUS does not allow the intermediate nodes to be
bypassed.  They are
"trusted" in that they have as much control over
the reply as the final
home server does.

  Alan DeKok.




-- 
Mip4 mailing list: Mip4ietf.org
    Web interface: https://w
ww1.ietf.org/mailman/listinfo/mip4
     Charter page: h
ttp://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

about | contact  Other archives ( Real Estate discussion Medical topics )