Subject: (radius) Proposed draft for Radius Security extensions using Kerberos v5

From: Kaushik Narayan <[email-masked]>
Date: Tue, 4 Jul 2000 22:40:17 +0530 (IST)

hi all,

    I am proposing security extensions to the Radius protocol using 
    Kerberos v5. Kerberos network authentication would be used to provide
    dynamic authentication for Radius . Kerberos would also provide a 
    framework for encrypting sensitive Radius attributes. I am attaching
    the proposed draft. Please review it and send your feedback.

  thanks,
   kaushik!

---

From: gurmeet <[email-masked]>
Date: Wed, 05 Jul 2000 11:12:18 +0500

Hi,

            Line 122 of the draft reads

     Note: Currently there is no way a NAS cannot determine whether a
   Radius server is Kerberized or not.

            I think what is meant is the opposite. So kaushik can you modify it.

        Secondly , as far as i think both the NAS and the radius server generally
sit on the ISP Lan only , so is there a definite requirement for enhancing the
security of the radius protocol.

with regards,

Gurmeet Singh

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Kaushik Narayan <[email-masked]>
Date: Wed, 5 Jul 2000 15:03:56 +0530 (IST)

gurmeet,

   hi!  Well all Radius requests are initiated by the NAS. The NAS needs
   to be aware of the type of the Radius server (whether Kerberized or not) 
   before it sends out a Kerberized Radius request. A Radius server would
   only respond to a requeut and it need not be aware of the nature of the 
   client. 
       A Kerberized Radius server would send the Kerberos information
   in the reply if it recieves a Kerberized Radius request and it would
   send a normal Radius reply on the reciept of a normal Radius request.
   A normal Radius server would just ignore the Kerberos attributes in
   a Kerberized radius request and treat it as a normal Radius request.
   It would be able to service the Radius request if the Radius data
   is in cleartext and would send back an Access-Reject  if the data
   is encrypted. Thus it's really the NAS which has to know the nature
   of the Radius server.

   There has been a growing demand for secure AAA protocols . The Radius 
   security extensions proposed provide a mechanism to optionally enable 
   both Kerberos authentication and/or encryption.  This feature can be 
   turned for a set of sensitive users and plain vannila radius can be 
   used for another set of users.

  kaushik!

-

---

From: [email-masked]
Date: Wed, 5 Jul 2000 12:58:25 -0700

A question has arisen about the definition of the
Framed-MTU attribute. draft-ietf-radius-radius-v2-06.txt
says:

"This Attribute indicates the Maximum Transmission Unit to be
configured for the user, when it is not negotiated by some other
means (such as PPP).  It MAY be used in Access-Accept packets.  It
MAY be used in an Access-Request packet as a hint by the NAS to
the server that it would prefer that value, but the server is not
required to honor the hint."

The question is whether the Framed-MTU size refers to the maximum
sized IP packet that may be sent, or the maximum size of the packet
with framing. For example, for Ethernet the maximum frame size is
1518 octets, but this corresponds to an IP packet size of 1500
(1518 minus 6 octets for source, 6 for dest, 2 for Ethertype and
4 for the FCS). 

-