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

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 10 Apr 2007 10:21:28 -0400

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.   
> 
> ...
> 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.   
> 
> ...
> 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.  
> 
> ...
> 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. 
> 
>   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. 
> 
> ...
> 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?    
> 
>   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. ...  
> 
>   Alan DeKok.

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 12 Apr 2007 13:01:22 -0700

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:[email-masked]] 
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

Thanks,

-Pete

> This would help to distinguish the non-goals from the rest of the

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

> "non-goal" text at the end of the sentence.   

Madjid>>OK, 
> to whether or not proxy servers need to understand the new

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.

>   RFC's 2618 through 2621 have been obseleted by RFC's 4668 through
Madjid>>thanks, I changed the references.

> statement that there are no IANA considerations. 

Madjid>>Ok.

> intermediaries are trusted.  Perhaps something else is meant by this
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])."

> described previously apply, and no additional security considerations

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

---

From: Alan DeKok <[email-masked]>
Date: Fri, 13 Apr 2007 02:54:14 +0200

> My immediate response is the proxies MUST not be affected either (same as

  I agree.

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

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 13 Apr 2007 10:08:37 -0700

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:[email-masked]] 
Sent: Thursday, April 12, 2007 5:54 PM
To: Madjid Nakhjiri
Cc: 'McCann Peter-A001034'; 'Mobile IPv4 Mailing List'; 'Avi Lior';
'Chowdhury, Kuntal'; [email-masked]
Subject: Re: draft-ietf-mip4-radius-requirements-01.txt

  I agree.

  Alan DeKok.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 16 Apr 2007 11:49:40 -0700

Ok, that is what I thought, thanks,

Madjid

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Friday, April 13, 2007 5:49 PM
To: Madjid Nakhjiri
Cc: 'McCann Peter-A001034'; 'Mobile IPv4 Mailing List'; 'Avi Lior';

> all, like I have right now?

  I don't think any text needs to be added, because it doesn't affect
the requirements.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 14 Apr 2007 02:48:51 +0200

Alan DeKok.