Subject: RE: ssh authentication and service authorization questions

From: "Dave Nelson" <[email-masked]>
Date: Wed, 1 Dec 2010 09:01:11 -0500

Bernard Aboba writes...

> RFC 5607 uses Service-Type=Framed-Management. Presumably
> that would be used in exchanges 1,2.

Not necessarily.  If the SSH service that's ultimately provided over the SSH
session is the terminal service, then Service-Type ought to NAS-Prompt or
Administrative.  Quite frankly the SSH model of multiplexed service delivery
challenges the RADIUS model of hint-and-provision. There's no single
meaningful hint as to the SSH service that can be provided by the RADIUS
client at the time of SSH session establishment.

> Section 6.1 states that the Framed-Management-Protocol
> attribute is used with Service-Type=Framed-Management.
> However, this isn't known until exchange 3 which will need
> to use Service-Type=Authorize-Only.

Right.

> Maybe the solution is just to clarify the Section 6.1 text?

I'd need to go back and look at it in detail, but I agree that RFC 5607
could be extended to handle a multi-round-trip RADIUS authentication and
authorization using Authorize-Only.  Certainly the RADIUS client that is
tied into the SSH implementation would be in a position to know when to send
an Authorize-Only request.  The largest challenge probably lies with the SSH
implementation, to revise it such that it calls the RADIUS client again
after session establishment but before service establishment.

Alan DeKok writes...

>   Or use Service-Type = Authorize-Only?
> 
>   It's intended for CoA, but there's no technical reason it couldn't be
> used here.
> 
>   i.e.
> 
> 1,2) Access-Request for initial session (user + password)
>      Access-Accept contains State
> 
> 3)  For each service:
> 
>        Access-Request + User-Name + State + Authorize-Only + ...
>        ...
> 
>   The State attribute ties the later Access-Requests to the first one.
> The RADIUS server can authorize individual services, based on their
> connection with the initial Access-Request.

Yes, I agree that this method could be used to authorize multiple SSH
services multiplexed over a single SSH session.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 1 Dec 2010 09:43:06 -0500

Juergen Schoenwaelder writes...
 
> I think it is important to clarify this aspect of RADIUS usage
> with protocols such as SSH. I support someone working on a revision
> of RFC 5607 that clarifies this detail.

Is this something that the NETCONF WG needs in support of its authentication
and authorization work?  I imagine that an RFC5607bis document would be in
scope as a potential RADEXT WG work item, if there is sufficient support for
it.

I could find some time to work on it, if there is support, and would
volunteer to co-author.

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 1 Dec 2010 10:24:29 -0500

> The NETCONF WG is not depending on this as far as I can tell.
> It is more that implementors do not know how to implement things
> from the specs we have produced. And I think this is a good reason
> to improve the specs.

Right.

I'll be happy to take a look at the discussion so far and propose some
possible revisions to address the issue of SSH service multiplexing in a
robust fashion.  If the chairs eventually deem that we should work on an
RFC5607bis document, I'll be happy to work on that, too.

My only concern is that we engage some SSH server experts, who can advise us
if we are asking for an interaction between SSH and RADIUS that will be
difficult to implement or deploy.