Subject: [Isms] RE: Summary of Authorize Only issue

From: "Nelson, David" <[email-masked]>
Date: Wed, 26 Jul 2006 16:19:32 -0400

Bernard Aboba writes...

> For this to be successful, the RADIUS server needs to know what 
> service is being requested by the NAS, so that it can limit the 
> attributes to those relevant to that service (or refuse to 
> authorize the service).  The service cannot be characterized by
> saying it is "authorize-only" -- that is merely a particular 
> (authorize-only) mode of a particular service which needs to
> be specified by the NAS.

I agree (100%).
 
> >In any of the use cases, it is important that the NAS, i.e.
> >the RADIUS Client, be able to communicate the kind of service
> >being sought via hint attributes to the RADIUS Server, in the
> >Access-Request message.
> 
> Service-Type is not a "hint". 

It is when it appears in an Access-Request message.  This is the context
of the foregoing paragraph.

> A RADIUS client that receives 
> an Access-Accept with an unknown Service-Type does not treat 
> the attribute as a "hint" -- it treats it as an Access-Reject. 
> This is mandatory behavior in RFC 2865.

I agree, when it appears in an Access-Accept message.

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

---

From: "Nelson, David" <[email-masked]>
Date: Thu, 27 Jul 2006 13:00:04 -0400

David Harrington writes...

> We separated the security and transport mappings from the message
> format in the RFC3411 architecture; SNMPv3 refers to a message format.

It also implies the only version with any real security.

> Please do not bind these concepts unnecessarily in your RADIUS
> proposal.

I think we can simplify the naming, as Dan suggests, and refer to SNMP
over SSH.  We can add a statement in the security considerations section
that strongly recommends use only with SNMP versions that have real
security, i.e. v3 (and higher).

> I can envision an SNMPv4 message processing model that uses an XML
> message encoding to improve compatibility with netconf and with data
> models from other SDOs.

Good luck with that!  :-)  

> I do not see a technical engineering reason to limit the RADIUS
> authorization to SNMPv3 over SSH, as compared to SNMP over SSH.

Right, but I think it might be fodder for the security considerations
section.

---

From: "Nelson, David" <[email-masked]>
Date: Thu, 27 Jul 2006 15:01:20 -0400

Jeffrey Hutzelman writes...
 
> The word "VPN" might be.  The point David is trying to get at is that
> there's a difference between SNMPv3 with SSHSM, and SNMPv3 with USM
over
> TCP tunnelled through an SSH port forwarder, but both can be described
as
> "SNMP over SSH".

Ah.  Point well taken.

> The solution to this is that we call the thing "SNMP over SSH
(RFCxxxx)".

Right.  The "branding" issue.  :-)  Maybe "SNMP via SSH Transport
Mapping Method"?