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

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

We have also received comments from Bernard Aboba.  They are
pasted below.

-Pete

Bernard Aboba wrote:
> Here are my comments.
> 
>    In the absence of IETF standardized RADIUS attributes for support
>    of MIPv4, different wireless SDOs have taken the path of developing
>    VSAs.  This will cause lack interoperability between these wireless
>    standards, potentially hindering mobility across these wireless
>    networks.
> 
> The use of VSAs by itself does not create an interoperability problem.
> I think you need to provide references here, and indicate why how it
> is proposed that interoperability issues will be addressed (e.g. by
> ensuring compatibility with Diameter MIPv4, which is already
> deployed).   
> 
>    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]
> 
> Requiring RADIUS proxies to "understand" RADIUS attributes (as
> opposed to just matching values) would require that existing proxies
> be upgraded to support this specification.  Is this really what is
> intended?   
> 
> I think you also need to say something about not requiring changes to
> the RADIUS standard data model. 
> 
>    The concern of using AAA protocols that use hop-by-hop security
>    (Diameter/RADIUS) to distribute keys is nothing new.
> 
> Is the intent to use RADIUS to distribute keys (as opposed to nonces)?
> The distinction is that a nonce can be sent in the clear, whereas a
> key needs to be protected. 
> 
>    In both Diameter and RADIUS the assumption is that intermediary
>    nodes are trusted.
> 
> As RFC 2607 indicates, RADIUS does not make this assumption in
> general. 
> Please delete
> this sentence.
> 
>    We have to rely
>    on the model that RADIUS intermediary nodes are to be trusted.
> 
> I would delete this sentence as well, since it seems to imply a
> change to the RADIUS trust model is required for MIPv4 (which I don't
> think is the case).  
> 
>    To protect against MITM attacks, RFC 2868 section 3.5 provides a
>    mechanism for encrypting RADIUS attributes (RFC 2868 section 3.5).
>    Diameter relies purely on IPsec to protect against MITM attacks. 
>    It can be argued that the encryption mechanism provided by RADIUS
>    is weak and therefore it is recommended to protect RADIUS
>    transactions using IPsec (e.g.  RADIUS protected by IPSec in
> [RFC3579]). 
> 
> The encryption mechanisms in RFC 2868 are designed to protect against
> snooping, not Man-in-the-Middle.  Diameter supports TLS as well as
> IPsec.  

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