Subject: RE: [Isms] RE: Follow up on Authorize Only issue

From: "Nelson, David" <[email-masked]>
Date: Tue, 25 Jul 2006 10:52:09 -0400

Bernard Aboba writes...

> Typically this is handled by utilization of a unique Service-Type
> or NAS-Port-Type value.  The RADIUS policy engine then selects the 
> attribute set to be returned based on these values.

The values of NAS-Port-Type are (almost exclusively) related to media
type:

     0  Async
     1  Sync
     2  ISDN Sync
     3  ISDN Async V.120
     4  ISDN Async V.110
     5  Virtual
     6  PIAFS
     7  HDLC Clear Channel
     8  X.25
     9  X.75
    10  G.3 Fax
    11  SDSL - Symmetric DSL
    12  ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase
        Modulation
    13  ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
    14  IDSL - ISDN Digital Subscriber Line
    15  Ethernet
    16  xDSL - Digital Subscriber Line of unknown type
    17  Cable
    18  Wireless - Other
    19  Wireless - IEEE 802.11
    20  Token-Ring  
    21  FDDI                                 
    22  Wireless - CDMA2000 
    23  Wireless - UMTS       
    24  Wireless - 1X-EV  
    25  IAPP   
    26  FTTP - Fiber to the Premises  
 27-29  Unassigned
    30  PPPoA - PPP over ATM  
    31  PPPoEoA - PPP over Ethernet over ATM 
    32  PPPoEoE - PPP over Ethernet over Ethernet  
    33  PPPoEoVLAN - PPP over Ethernet over VLAN  
    34  PPPoEoQinQ - PPP over Ethernet over IEEE 802.1QinQ 

While there have been proposals to over-load NAS-Port-Type with
application layer protocol information, I think this is not a good idea.

> As far as I know there is no specification for SSH authentication
> support within RADIUS so I'm not sure if this is true or not.

That is one of the issues that we have addressed in the NAS-Management
draft. (
http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho
rization-03.txt )  SSH implementations use RADIUS today for
authentication, with or without a formal specification.  What is lacking
is a set of authorization attributes targeted at SSH, SNMP over SSH, and
similar use cases.

> For example, as I understand it SSH can support authentication 
> mechanisms such as Kerberos which are not supported in RADIUS.

SSH authentication support indeed extends beyond RADIUS.

> In this case it sounds like the NAS-Port-Type might be "SSH" but the
> Service-Type might be "SNMP".

Uh, something like that.  Actually, in the NAS-Management draft we
recommend that the Service-Type attribute be "Framed-Management" and the
(new) Framed-Management-Protocol attribute be "SNMPv3".  I think that
this is much cleaner than overloading the NAS-Port-Type.  Once could
argue that a generic service such as Framed-Management, with subsidiary
attributes such as Framed-Management-Protocol, is "too much".  One could
flatten all the combinations into a set of new service types.  I think
that the approach in the NAS-Management draft is more in line with
traditional RADIUS usages (e.g. Service-Type = Framed, and
Framed-Protocol = PPP).

> I think this depends on whether RADIUS can support all the required
> authentication methods.  If not, then either that support needs to 
> be added to RADIUS or only authorization will be available.

Right.  For those deployments that are using non-RADIUS authentication
today, the SSHSM usage of RADIUS will likely be for authorization only.
The goal of the ISMS WG is to re-use existing AAA infrastructures.
Where RADIUS is already in use, it would naturally be used for both
authentication and authorization.  Where it is not already in use, it
may be used only for authorization.
 
> Question:  In the case where SSH is used, do you just need SSH 
> attributes, or are SNMP attributes required there as well?

This is addressed in the NAS-Management draft.  Provisioning of "plain"
SSH, SNMPv3 over SSH, and other protocol combinations are described.
So, yes, more than a single attribute (or single service provisioning
description) is necessary.

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 25 Jul 2006 12:00:40 -0400

"Nelson, David" <[email-masked]> wrote:
> this is much cleaner than overloading the NAS-Port-Type.

  I agree.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 25 Jul 2006 09:36:58 -0700

>Actually, in the NAS-Management draft we

This makes sense.

>today, the SSHSM usage of RADIUS will likely be for authorization only.

Does the Service-Type of "Framed-Management" imply authorization-only?  Or 
is it possible for authentication to be requested as well?   For example, 
what attributes are used in existing SSH implementations acting as a RADIUS 
client?