RE: Please review draft-carroll-dynmobileip-cdma-04.txt

["Nelson, David" <dnelson@enterasys.com>]

Thomas Narten writes...

> The above document has been under IESG review for some time. The
> central issue that has been discussed is that the document extends
> radius, in ways that violate a "MUST NOT" clause of the radius spec.

I'm reading the document (again) now.

It seems that the controversy is captured in this sequence of steps,
that describes the data flow in Figure 4 of the draft.

    " 6. The RADIUS AAA Server compares the authenticated MSID (sent 
         from the PDSN) with the MSID in its subscriber database 
         (associated with the NAI).  If the AAA MIP Update State Field 
         is set to UPDATE KEYS (1), the RADIUS AAA Server rejects Packet

         Data access and orders a MIP key update. 
       
      7. The RADIUS AAA Server sends an Access Reject (code = 3) message

         to the PDSN with the MIP_Key_Update_Request RADIUS VSA. 
       
      8. The PDSN converts the Access Reject to a MIP Registration Reply

         (RRP) with a MIP_Key_Request MIP VSE and sends the RRP to the 
         MN.  RRP Code = 89 (Vendor Specific).

      9. The MN sets the MN MIP Update State = UPDATE KEYS.  If the MN 
         has no pre-generated and pre-encrypted the MIP_Key_Data 
         payload, the MN MUST generate the MN_AAA key, MN_HA key, Chap 
         key, MN_Authenticator, and AAA_Authenticator in accordance with

         RFC 1750.  Except for the Public Key Identifier, all generated 
         values MUST be encrypted using the pre-loaded RSA Public 
         (encryption) key.  The newly generated MN_AAATEMP Key and 
         MN_HATEMP MUST be used to calculate the MN-AAA and Mobile-Home 
         Authentication Extensions for the current RRQ.  Note: the MN 
         MAY pre-compute the MIP_Key_Data payload by checking whether a 
         payload exists during each MN power-up or application 
         initiation. 
       
      10. The MN sends the RRQ with MIP_Key_Data MIP VSE to the PDSN. 
       
      11. The PDSN converts the RRQ to a RADIUS ARQ with MIP_Key_Data 
         RADIUS VSA and forwards the ARQ to the home RADIUS AAA Server.

         The MSID is included in the ARQ. "

I don't know if this draft is describing an existing implementation, in
which case "on the wire" protocol changes are not likely to be welcomed,
or whether this is a protocol under development.  I would suggest that
there may be alternate ways for the protocol to achieve its operational
goals, without violating any MUSTs or MUST NOTs in the base RADIUS RFCs.

Would it be possible, for example, for the HAAA, in step 7, to send an
Access-Challenge message instead of an Access-Reject?  This approach
would have two benefits, IMHO.  First, it would avoid the normative
requirements violation of using an Access-Reject.  Second, the
traditional data flow in RADIUS, when the RADIUS Server is not satisfied
with something in an Access-Request from a RADIUS Client and wishes to
prompt the client for more (or different) information, is to send a
Access-Challenge back to the client.  My reading of the data flow in
steps 8 - 11 leads me to believe that this is just that sort of
"prompting for more/different information" scenario that is
traditionally handled using an Access-Request, Access-Challenge,
Access-Request sequence.

-- Dave