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

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Avi Lior <> supposedly scribbled:

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

Leaving out the change in semantics for the Access-Reject message?
& the fact that it is a VSA, not even a standard attribute?

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

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