[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FWD: Re: draft-carroll-dynmobileip-cdma-04.txt
The RFC 2865 prohibition is strictly adhered to in all RADIUS RFCs - the
only attributes allowed in an Access-Reject are those which can inform the
user as to why they have been denied access (Reply-Message,
EAP-Message/Failure, etc.) or those that route the message to the right
NAS/Port/User (Proxy-State, etc.).
In particular, VSAs MUST NOT be included within an Access-Reject, since
that would open the door to providing service to users to whom access has
been denied. Given the MUST NOT, existing NAS devices may silently
discard these attributes if sent.
Frank does make an argument that this particular VSA is used for the
purpose of informing the user that they have been denied access and need to
change keys. However, the document also requires that the NAS not tear
down service to the user after receipt of an Access-Reject:
Upon receipt of an Access Reject containing the
MIP_Key_Update_Request VSA, PDSN MUST send an RRP to the MN with the
MIP_Key_Request VSE. The PDSN MUST use the RRP error code = 89
(Vendor Specific) and MUST not tear down the PPP session after
transmission.
So overall, I'm not clear about whether in fact Access has been denied, or
not. The test would be whether the user could gain the ability to send a
network layer packet (e.g. complete IPCP) without having to
reauthenticate.
Had such an attribute been sent within an Access-Challenge rather than an
Access-Reject, there would be no issue at all. I'd also argue that if a
standard attribute had been used, rather than a VSA (such as if the
message were sent within a Reply-Message attribute), there would be no
issue.
On Tue, 15 Feb 2005, Thomas Narten wrote:
> Bernard,
>
> Not sure how much you (or others) want to engage in this
> discussion. We've had it to some extent before.
>
> But if we were to, would the best course be to have this thread moved
> to AAA-doctors so that at least there is broader discussion? I'd
> prefer that in that it would be more open, and others could chime in
> as they see fit.
>
> Also, AAA-doctors hasn't really taken a definitive stand on whether
> they want to block this document. Maybe having a definitive stand is
> asking too much...
>
> In any case, the IESG is discussing Thursday, so there will be a big
> push to come to closure on this one.
>
> If the IESG were to let it go forward, how draconian of an IESG note
> would be appropriate?
>
> I'm appending two messages below; they seem to summarize the current
> state of deployment.
>
> Thomas
>
> ------- Forwarded Message
>
> From: Frank Quick <fquick@qualcomm.com>
> To: Thomas Narten <narten@us.ibm.com>
> Cc: RFC Editor <rfc-editor@rfc-editor.org>, gerry.flynn@verizonwireless.com,
> "Carroll, Christopher P." <Ccarroll@ropesgray.com>,
> Russ Housley <housley@vigilsec.com>, Sam Hartman <hartmans-ietf@mit.edu>
> Date: Tue, 15 Feb 2005 11:25:30 -0800
> Subject: Re: draft-carroll-dynmobileip-cdma-04.txt
>
> Thanks for the update. Sorry this has been such a struggle.
>
> I am unaware that anyone other than Verizon Wireless is actually using
> DMU. Within their network it is my understanding that every CDMA EV-DO
> device uses DMU. (Gerry, anything to add?)
>
> The discussion of this central issue terminated shortly after I pointed out
> that RFC 2869, Radius extensions contains three attributes that are added
> as allowed in access-reject (see 5.19). Perhaps we can continue the
> discussion.
>
> One could argue that 2865's prohibition, "No other Attributes (except
> Proxy-State) are permitted in an Access-Reject" applies only to the
> attributes defined in 2865, and not to extensions as defined in
> 2869. Further, I suppose the philosophical stance taken below would argue
> that these new attributes are not intended to be delivered to the user,
> hence do not violate the (unwritten) intent of 2865. But I think the
> philosophy here is misguided, and overly restrictive on the use of
> vendor-specific attributes.
>
> The comment is made that 2865 does not allow any service provisioning
> attributes in Access Reject. However, 2865 does not contain the phrase
> "service provisioning", nor do any of the attributes defined in 2865 appear
> to have anything to do with service provisioning. I doubt the authors of
> 2865 anticipated the over-the-air provisioning that is performed in
> cellular systems, which would explain why there is no allowance for it. To
> perform provisioning of the sort done in DMU, the AAA must have a means to
> indicate to the terminal and serving system that the terminal should be
> denied access to Internet service until it has performed a key
> update. That is the function of the vendor-specific attribute in the
> Access Reject.
>
> The only alternative I can see is to add a new message to RADIUS to signal
> that a key update is required. That avoids all the rules in 2865, though
> perhaps the philosophical objection might resurface in a different
> form. In any case, I hope we will all agree that extending the use of
> vendor-specific attributes is far simpler than adding a new message.
>
> Given the state of affairs, the IESG can block the publication of this RFC,
> but it is too late to prevent the use of DMU. The reality is that IETF has
> little control over what vendors do with vendor-specific
> attributes. Perhaps that's as it should be, otherwise why allow such
> attributes to exist?
>
> At 01:37 PM 2/15/2005 -0500, Thomas Narten wrote:
> >Hi.
> >
> >The IESG is (once again) going to discuss this document during its
> >teleconference on Thursday. My hope is we'll come to some closure.
> >
> >For RFC Editor submissions, the IESG is now using RFC 3932 as a guide
> >for how to review such submissions. Using 3932 as a guide, the
> >following point is at issue:
> >
> > > 5. The IESG thinks that this document extends an IETF protocol in a
> > > way that requires IETF review and should therefore not be
> > > published without IETF review and IESG approval.
> >
> >As has been discussed before, the central issue with this document is
> >its apparent extension of radius, by including an attribute where it
> >is specifically forbidden to do so via an explicit MUST NOT. Different
> >people may disagree as to the significance of this change, but one
> >expert indicates:
> >
> > > The particular case under discussion is somewhat unique, in that it not
> > only
> > > violates a MUST NOT -- but it also represents a major change to the
> > security
> > > model of the protocol in question.
> > >
> > > Authentication, Authorization and Accounting protocols are built on a very
> > > fundamental idea: that AAA servers can unambigously allow or deny
> > access to
> > > the network. Denying access means that the user cannot access network
> > > services, except possibly to re-attempt authentication.
> > >
> > > RFC 2865 Section 2 states:
> > >
> > > "If desired, the server MAY include a text message in the Access-Reject
> > > which MAY be displayed by the client to the user. No other
> > > Attributes (except Proxy-State) are permitted in an Access-Reject."
> > >
> > > Table 5.44 of RFC 2865, indicates that inclusion of a vendor-specific
> > > attribute (or indeed any service provisioning attribute) in an
> > Access-Reject
> > > is a MUST NOT:
> > >
> > > Request Accept Reject Challenge # Attribute
> > > 0+ 0+ 0 0+ 26 Vendor-Specific
> > >
> > > There is a simple reason for this.
> > >
> > > Since an Access-Reject results in denied access, there is no service that
> > > can be provided to the user, other than perhaps routing the Reject message
> > > to the right NAS or explaining to the user why they have been denied
> > access.
> > > To provision a service to a denied user would imply that they have not
> > > been denied access after all.
> > >
> > > Provisioning a service with an Access-Reject is like redefining a "Deny"
> > > packet filter to allow packets to pass through, or defining a "null
> > > authentication" mode for IKE.
> > >
> > > The RADIUS specifications generally take a lax attitude toward security,
> > > doing only the minimal amount of work to avoid wholesale compromise. So
> > > when MUST NOT language is used, that's a sign that the practice in
> > question
> > > is not just another bad idea, but so bad that even RADIUS could not abide
> > > it.
> >
> >Anyway, reviewing some of the mail on this topic, I found:
> >
> >Frank Quick <fquick@qualcomm.com> writes:
> >
> > > Date: Wed, 29 Oct 2003 11:04:02 -0800
> >
> > > I know I received these questions, and I thought that I had even sent a
> > > response, but similarly I can find no record of either. Subject to
> > > comment/change by Verizon, here is a tentative answer.
> >
> > > - does this describe something that has already been deployed? If
> > > so, by whom and how widely?
> >
> > > Yes, it's deployed by the vendors supporting Verizon Wireless' 1xEV-DO
> > > system, which is now commercial in Washington, DC and San Diego, CA.
> >
> > > - Is this something that is Verizon-specific? Are other operators
> > > using it (or planning on using it)? If Verizon-specific, it would
> > > be customary to change the title to make this more clear.
> >
> > > At the moment it is only in use by Verizon Wireless, however the intent of
> > > publishing is to make it available for others who may wish to use it.
> >
> >Can you comment on the current state of use/deployment of this system?
> >Has it expanded beyond what is described above?
> >
> >Thomsa
>
>
> Frank Quick
> office +1-858-658-3608 fax +1-858-651-1940
> portable +1-619-890-5749
> paging fquick@pager.qualcomm.com
> RSA: 29EA D619 31F2 B4D3 8815 3D59 4340 FA43
> D-H: 2A24 131C D38F 12E6 4D6A 46EE 8BBF B50A 754E F63D
>
> ------- End of Forwarded Message
>
> From: Gerry.Flynn@VerizonWireless.com
> To: narten@us.ibm.com, fquick@qualcomm.com
> Cc: rfc-editor@rfc-editor.org, Ccarroll@ropesgray.com, housley@vigilsec.com,
> hartmans-ietf@mit.edu
> Date: Tue, 15 Feb 2005 14:02:25 -0500
> Subject: RE: draft-carroll-dynmobileip-cdma-04.txt
>
> Thomas
>
> Thank you for the e-mail and heads up with respect to additional discussion
> of our submission. As a matter of update to Frank Quick's 29 October 2003
> note, Verizon Wireless has expanded its commercial deployment of 1xEV-DO to
> cover over 75 million population across thirty large metropolitan areas. We
> have also shared DMU with other Operators both domestically and
> internationally and intent is to point Operators to IETF for use of this
> submission.
>
> Please advise if we can provide any additional information to you in support
> of the submission.
>
>
> Thank you
>
> Gerry
>
> _____________
> Gerry Flynn
> Verizon Wireless
> Adv. Technology & Strategy
> Phone: (908)-306-6895
> Fax: (908)-306-7240
> E-Mail: gerry.flynn@VerizonWireless.com
>
>
> From: Gerry.Flynn@VerizonWireless.com
> To: fquick@qualcomm.com, narten@us.ibm.com
> Cc: rfc-editor@rfc-editor.org, Ccarroll@ropesgray.com, housley@vigilsec.com,
> hartmans-ietf@mit.edu
> Date: Tue, 15 Feb 2005 14:34:36 -0500
> Subject: RE: draft-carroll-dynmobileip-cdma-04.txt
>
> Frank
>
> We have had discussions and shared information on DMU with several Carriers
> who are planning to launch Ev-DO networks but they are not commercial yet.
>
> _____________
> Gerry Flynn
> Verizon Wireless
> Adv. Technology & Strategy
> Phone: (908)-306-6895
> Fax: (908)-306-7240
> E-Mail: gerry.flynn@VerizonWireless.com
>