RE: Comments on draft-carroll-dynmobileip-cdma-04.txt

[Avi Lior <avi@bridgewatersystems.com>]

Note that we currently have a draft in MIPv4 WG to define a similar
procedure.

Okay....

Here is some proposed text....What do people think.


This document extends RADIUS in the following way:

The document returns an attribute in an Access-Reject message. According to
RFC-2865 an Access-Reject packet MAY only include Reply-Message and
Proxy-State.

Subsequent RFCs allow for other attributes to be included in an
Access-Reject packet but these are included to indicate the reason the
authentication/authorization has failed.  Given the use in this document an
Access-Challenge packet would have been more appropriate.


Regarding Bernards comment:

7.9 Network Message Security

   The security of the MN-HA keys delivered from the RADIUS AAA server
   to the MIP home agent requires confidentiality for network messages
   containing such keys.  The specification of security requirements for
   network messages is the responsibility of the operator, and is
   outside the scope of this document. (Note that similar considerations
   apply to the distribution of Shared Secret Data, which is already
   transmitted between nodes in the ANSI-41 network.)


As I understand the actual implementation, the MN-HA key (and others) are
protected using the technique in 2868.  If that is true then, the authors
should state that in the document. 

Regarding Bernard's comment on Message-Authenticator.  Not 100% sure, but
our opinion is that Message-Authenticator is not required. The procedure is
end-to-end and does have a MITM vunerability (see their comment) and we are
not sure whether the use of message authenticator will improve security.  We
would have preffered to see Message-Authenticator.

Avi

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:gwz@cisco.com] 
> Sent: Thursday, March 03, 2005 6:30 PM
> To: 'Thomas Narten'; 'Avi Lior'
> Cc: 'Frank Quick'; christopher.carroll@hbsr.com; 
> radiusext@ops.ietf.org; 'W. Mark Townsley'
> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> Thomas Narten <mailto:narten@us.ibm.com> supposedly scribbled:
> 
> ...
> 
> > 
> > Given that the protocol is deployed, and most folks seem to 
> think it's 
> > better to document something (that is widely deployed) than
> not,
> 
> It's not clear to me that this protocol is widely deployed, 
> but possibly my understanding of the term is deficient.  My 
> understanding is that this is a proprietary protocol, 
> deployed in a single 3G cellular network (Verizon); 
> furthermore it appears that this protocol will only be useful 
> with so-called "captive" mobile devices, and not in a roaming 
> environment.  If I'm correct on those points, then I wouldn't 
> consider it to be "widely deployed".
> 
> > adding such a note as outlined above seems like a reasonable way
> out
> > (to me).   
> > 
> > What do others think? Which particual radius extensions would need
> to
> > be called out for attention?
> 
> The only actual violations that I can see are 1) the 
> inclusion of vendor-specific attributes in the Access-Reject 
> message and 2) the redefinition of the semantics of the 
> Access-Reject message to _not_ terminate the PPP connection.  
> Given your explanation (not reproduced), I suppose we must 
> ignore the security issues/questions raised by Bernard & myself.
> 
> > 
> > Thomas
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel
> 

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