Re: [secdir] Review of draft-ietf-isms-radius-usage-05

[Eric Rescorla <[e-mail]>]

At Tue, 5 May 2009 23:44:50 -0400,
Dave Nelson wrote:
> 
> Eric Rescorla writes...
> 
> > Subject: Review of draft-ietf-isms-radius-usage-05
> 
> Thanks for your review and comments.
> 
> > IMO, this document would benefit from a rewrite that makes it a
> > lot clearer to someone not enmeshed in the WG.
> 
> Umm.  OK.  That's a bit disheartening to hear, but useful feedback.
> 
> > As far as I can tell, the idea is to explain how to outsource 
> > some of the authorization decisions to RADIUS.
> 
> Correct.
> 
> > I found this document extremely difficult to read. I realize that
> > My big question is how the user authentication decisions are
> > expected to be split between (e.g., SSH), and RADIUS. For
> > example:
> > 
> > - If the user has a password, who checks it the RADIUS server
> >   or the NAS? RADIUS certainly can do this.
> 
> The RADIUS server makes the authentication decision.  If the credential is a
> password, as is the typical use case, the password is sent (hidden) in a
> RADIUS Access-Request message.
> 
> > - If the user is authenticating with SSH pubkey auth, who
> >   checks that?
> 
> The SSH server, i.e. the NAS.  SSH is used to create a protected transport
> session (a tunnel, if you will) and the RADIUS credentials are obtained from
> the SSH server implementation in the NAS and used by the RADIUS client in
> the NAS to authenticate the user with the RADIUS server.  Of course, it has
> to be an authentication method that RADIUS supports, and SSH public key is
> not one of those.

so, this is what concerns me: architecturally these are pretty
different--and challenge-response may be different yet. That
seems like it deserves some analysis.

-Ekr