Subject: [Isms] RADIUS ssh and ISMS

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Aug 2005 13:27:31 -0400

>>>>> "David" == David B Harrington <[email-masked]> writes:

    >>  * Mapping describing how ssh is used between the two snmp
    >> engines

    David> Juergen S. and I have been working on the assumption that
    David> the TMSM document, or something similar, will describe how
    David> any transport-mapping can be used to work between engines,
    David> possibly including such issues as session management.

Agreed.

    >>  * Mapping describing what radius attributes are used to
    >> populate securityname and other SNMP parameters

    David> Is the RADIUS user authentication different from the SSH
    David> user authentication?

I don't know how to answer this.

In general, if radius is being used by an ssh implementation, here is
how it works.  The ssh implementation will use password auth (or
keyboard interactive) over the wire between the client and server.
The server will turn this into a radius authentication request.

The server may later get radius authorization information to for
example confirm that the session is allowed at the current time.

    David> It appears to me that in the SNMP-to-SSH mapping,
    David> securityName can be obtained from the user name contained
    David> in the SSH_MSG_USERAUTH_REQUEST message. This works for
    David> publickey, password, and host-based approaches.

People have argued on this list that that's not very deployable.  In
particular they believe you need to populate VACM entries for every
ssh user who might use the system.  Instead there has been some
discussion of having the security model map the model-specific
authentication name (the name in the userauth_request message for ssh)
into some SNMP security name.  The idea is that whatever central
database is providing your authentication information might also want
to provide securityname mapping.  Then you would only need to consider
VACM entries for the range (instead of domain) of that mapping.

If you believe this is valuable you could create RADIUS attributes to
store this information.

If you just want to use the name from the userauth_request message as
your securityname then you need say nothing about RADIUS, Kerberos or
really any particular authentication method.

    David> I don't see any mention of RADIUS in the "SSH
    David> Authentication Protocol" draft. If RADIUS is used to
    David> provide the SSH authentication, how do we get the username
    David> from RADIUS to pass via the SSH_MSG_USERAUTH_REQUEST into
    David> the SNMP engine? Or do we go directly to RADIUS to get the
    David> username, and if so does that also work for other backend
    David> authentication metyhods, such as publickey, password, and
    David> host-based or would every authentication method require its
    David> own user-mapping technique? Is there a document already in
    David> existence that describes how to use RADIUS for SSH user
    David> authentication?

Every backend would require its own mapping technique.  Note that
backends don't map well to ssh userauth mechanisms.  For example the
Kerberos backend can be used with password, keyboard interactive,
gssapi-with-mic and gssapi-keyex user authentication methods.  The
RADIUS backend can be used with password and keyboard interactive.
You could use LDAP with password, keyboard interactive, and publickey.

    >>  * Document describing the ssh security model; probably this
    >> can be folded in as part of the first document.  This document
    >> allows for the securityname to be mapped and points to the
    >> radius document as an example of how one does it in a radius
    >> environment.  Discusses mapping to level; if ssh is used as it
    >> traditionally is used, everything maps to authpriv.  Otherwise
    >> specify level in terms of the over the wire ssh behavior.

    David> As I envision it, the securityName must be extracted
    David> somehow form the messages passed by the underlying
    David> protocol, such as from the
    David> SSH_MSG_USERAUTH_REQUEST. Extracting an SSH username will
    David> be different than extracting a TLS username, and different
    David> than extracting a SASL username, and so on, so I envision a
    David> different document for each, unless the work to be done for
    David> each is really minimal enough to fit into an appendix of
    David> the TMSM document.

I was hoping the working group would not define all these
encapsulations unless there is actually a need to do so.

    David> As you state, securityLevel may simply always be authpriv,
    David> but since SSH authentication can utilize different methods,
    David> do we need to *check* whether auth and priv are provided by
    David> the selected method? If so, how do we do this? 

So, the SNMP level seems to refer more to per-packet protection than
to properties of the authentication method.  It is true that for
per-packet protection you need certain minimum properties from the
authentication method.  Any authentication method that meets the
requirements of the ssh architecture will give you these properties
(mutual authentication and binding of keys seem to be all that is
required).  Then the only question for level is whether the channel is
using confidentiality and whether the channel is using integrity.
While ssh does support turning off confidentiality and integrity, it
is strongly recommended that you never do so.  Turning off
confidentiality would violate the security assumptions of
authentication methods like password.  I would recommend simply
requiring that ISMS uses of ssh keep confidentiality and integrity on
and then define the level to be authpriv.  Many ssh implementations
don't even support turning off confidentiality or integrity even
though it is allowed by the spec.

    David> The securityModel will probably be just a single one for
    David> the SSH security model, but we may need different
    David> securityModel identifiers depending on whether we use
    David> publickey or password or host-based or some other method of
    David> authentication, if that can affect how access control might
    David> be applied. If we do need this, then we need to know how to
    David> determine which authentication method was used and how to
    David> report that to the SNMP engine.

I recommend a single security model.  If you do something else, you
make it harder for people to use new authentication methods with SNMP.
That is undesirable.

    >> In particular I don't think you need a document describing how
    >> ssh authenticates via radius, although as I discuss I do think
    >> you will need documentation of how authorization information is
    >> obtained from radius.

    David> Do you consider it within the current charter scope to
    David> discuss how authorization information is retrieved from
    David> RADIUS? Should we be trying to address this issue as well
    David> as the authentication issue in the new charter?

I believe that model-specific security name mapping is within scope.
I believe that VACM population and other authorization information is
out of scope.  I'll certainly listen to arguments that expand the
scope, although given our problems reaching consensus so far they
would need to be very good.

--Sam

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 12 Aug 2005 10:50:15 -0700

Hi -

> From: "Sam Hartman" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, August 12, 2005 10:27 AM
> Subject: [Isms] RADIUS ssh and ISMS
...
> would need to be very good.
...

Do you consider the user->group mapping to be out of scope, because
it is associated with authorization?

I strongly agree that delivery of the other information found in
VACM should be out of scope, but I believe it would be a mistake
to not address the user->group mapping.  If the user->group mapping
is not addressed, the isms solution would not be appreciably better
than USM, from the perspective of when management systems would
need to push security configuration information into the SNMP engines
scattered about an administrative domain.  Specifically, the only work
"saved" would be for key updates.  For user addition, removal, and
re-categorization, there'd by no improvement.  That doesn't sound
like much of a win.

Randy

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Aug 2005 14:13:23 -0400

>>>>> "Randy" == Randy Presuhn <[email-masked]> writes:

    Randy> Hi -
    >> From: "Sam Hartman" <[email-masked]> To:
    >> <[email-masked]> Cc: <[email-masked]> Sent: Friday, August
    >> 12, 2005 10:27 AM Subject: [Isms] RADIUS ssh and ISMS
    Randy> ...
    >> I believe that model-specific security name mapping is within
    >> scope.  I believe that VACM population and other authorization
    >> information is out of scope.  I'll certainly listen to
    >> arguments that expand the scope, although given our problems
    >> reaching consensus so far they would need to be very good.
    Randy> ...

    Randy> Do you consider the user->group mapping to be out of scope,
    Randy> because it is associated with authorization?

    Randy> I strongly agree that delivery of the other information
    Randy> found in VACM should be out of scope, but I believe it
    Randy> would be a mistake to not address the user->group mapping.
    Randy> If the user->group mapping is not addressed, the isms
    Randy> solution would not be appreciably better than USM, from the
    Randy> perspective of when management systems would need to push
    Randy> security configuration information into the SNMP engines
    Randy> scattered about an administrative domain.  Specifically,
    Randy> the only work "saved" would be for key updates.  For user
    Randy> addition, removal, and re-categorization, there'd by no
    Randy> improvement.  That doesn't sound like much of a win.

I actually think that allowing to remap securityname gives you most of
the flexibility you need.  You could create role accounts at the VACM
level, add those to VACM groups, and then map encapsulated
authentication to those role accounts.

That said, group mapping may not be much more difficult than name
mapping.  I'm not sure whether it is in scope, but if the working
group believes group mapping is required or can easily be done, I
don't have a problem doing it.

--Sam