[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Isms] RE: Follow up on Authorize Only issue
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.
--
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/>