RE: draft-ietf-mip4-radius-requirements-01.txt

Thanks Pete for shepherding the document so far.

Hi Alan,

I picked your email off your DTLS draft, so I hope it is the
right email.
Thank you for the review. Please see in line comments,

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).

R,

Madjid

-----Original Message-----
From: McCann Peter-A001034 [mailto:pete.mccannmotorola.com] 
Sent: Tuesday, April 10, 2007 7:21 AM
To: Mobile IPv4 Mailing List
Cc: Madjid Nakhjiri
Subject: FW: draft-ietf-mip4-radius-requirements-01.txt

We've received a review of
draft-ietf-mip4-radius-requirements-01.txt.
It is copied below.  Thanks to Alan DeKok for reviewing the
document.

Madjid, can you address these comments?

Thanks,

-Pete

Alan DeKok wrote:
>   In the introduction, under "non-goals", it
would be good to indent
> the non-goal items by 3 spaces, and add a bullet ('o'
or '-' or '*').
> This would help to distinguish the non-goals from the
rest of the
> text.   
> 

Madjid>>ok, I created two different sections, one for
goals and one for
non-goals and added bullets to each.

> ...
> Extend RADIUS in a way that fulfills the full list of
requirements in
>    RFC 2977 is a non-goal
> ..
> 
>   The sentence should have a trailing period, and
should be
> re-written to be in active voice, like the rest of the
document. 
> e.g. "Extending RADIUS...".  It is also not
necessary to repeat the
> "non-goal" text at the end of the sentence.  

> 

Madjid>>OK, 
> ...
> It is however required of the RADIUS servers (and
possibly proxies)
>    to be able to understand and process the attributes
described in
>    this specification to perform verification of
authentication
>    extensions specified in [MIP4CHAL]
> ...
> 
>   Possibly proxies?  The document should be make a
clear statement as
> to whether or not proxy servers need to understand the
new
> attributes.  

Madjid>>I would think the same rules for servers
applies to proxies, but let
us get back to you on that. I will separate the sentences
for servers and
proxies for now.

> ...
> All RADIUS work MUST be backward compatible with
existing RADIUS
>    RFCs, including RFCs 2618-2621, 2865-2869, 3162,
3575, 3576, 3579,
>    and 3580.
> ...
> 
>   RFC's 2618 through 2621 have been obseleted by RFC's
4668 through
> 4671. 
> 
Madjid>>thanks, I changed the references.

>   Also, if the RADIUS work here is backwards compatible
with the
> existing RADIUS RFC's, then RADIUS proxies *cannot* be
affected by
> the new authentication extensions.  
> 
> ...
> 1.2.  IANA Considerations
> ...
> 
>   This document does not allocate numbers, so there
should be a
> statement that there are no IANA considerations. 
> 
> ...

Madjid>>Ok.

> 2.  security considerations
> ...
> 
>   Nit: Capitalization.
>
> ...
> To protect against MITM attacks, RFC 2868 section 3.5
provides a
>    mechanism for encrypting RADIUS attributes (RFC 2868
section 3.5).
> ...
> 
>   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.

   When it comes to protecting attributes in Access Request,
RFC 2868
   section 3.5 provides a mechanism for encrypting RADIUS
attributes
   (RFC 2868 section 3.5).  There is also work in progress
to define key
   wrap mechanisms for RADIUS [zorn-radius-keywrap].  The
key wrap
   process can be used to transmit sensitive material, such
as keys,
   that require specific privacy protection.  It is also
possible to
   protect RADIUS transactions using IPsec (e.g. 
[RFC3579])."

>   This sentence should be clarified, or removed.
> 
>   As this document defines requirements and not
protocols, much of
> the security considerations section could be removed,
and replaced
> with text similar to the following:  
> 
> ...
>   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. ...  

Madjid>>added your text to the section, as shown
above.

> 
>   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/

RE: draft-ietf-mip4-radius-requirements-01.txt

Thread: RE: draft-ietf-mip4-radius-requirements-01.txt