Subject: Re: [Isms] Limited time to charter

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Aug 2005 11:39:19 -0400

This is very much an individual opinion.  The only thing close to this
I would say as an AD is to make sure your architecture is not over
specified to the point where it makes implementation difficult.  For
example I would say that requiring implementation of specific APIs
would be actively harmful.  But the rest of this message is just my
personal thoughts.

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

    David> Hi, So do we have any volunteers to work on documenting how
    David> SSH authenticates its users using RADIUS or Kerberos, and
    David> makes the model (e.g. RADIUS), user (user-auth), and level
    David> (authentication and encryption services) accessible in a
    David> standard manner within SSH, or in an SSH-API for protocols
    David> using SSH services?
I'm not entirely sure that's necessary.  Traditionally outside of a
few limited areas the IETF has not discussed implementation details
like how one subsystem (such as the ssh radius plugin) makes
information available to another subsystem (the snmp ssh subsystem).
There are a few exceptions to this and I'll note that SNMP is
traditionally one of these exceptions.

If you can find someone to do this work and if they manage to do so in
a way that does not limit what ssh implementations you can use or
overly constrain implementation then that will be a good result.

However in order to succeed at a standardization level, you don't
quite need that.  I think all you need is documents describing bits on
the wire and an applicability statement (in the strict sense of
section 3.2 of RFC 2026) describing required to implement behavior.

In particular, I think the minimum set of documens you would need is:

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

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

* 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.

* An applicability statement that sets up reasonable mandatory to
  implement methods.  You'll probably want to require radius support although of course that is a WG decision.

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.

Note that's what I think you will need to succeed at a standards
level.  Your implementers may need more guidance to actually implement
the standards.

--Sam

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

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 12 Aug 2005 12:56:14 -0400

Comments inline. 

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Friday, August 12, 2005 11:39 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Isms] Limited time to charter
> 
> 
> would be actively harmful.  

I agree. I'm not looking for APIs; I'm, looking for the source of the
data that needs to be mapped to the SNMP concepts securityModel,
securityName, and securityLevel.

> But the rest of this message is just my
> personal thoughts.
> 
> 

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

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

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

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

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

>   the over the wire ssh behavior.

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

As you state, securityLevel may simply always be authpriv, but since
SSH authentication can utilize different methods, do we need to
*check* whether auth and priv are provided by the selected method? If
so, how do we do this? In a programming world where support for
dynamic link libraries or other dynamic add-ons, how do we know
whether an add-on does or does not provide auth and priv? Is there
something in the SSH standard that requires all add-ons to assert the
securitylevel provided?

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

>   implement methods.  You'll probably want to require radius 
> support although of course that is a WG decision.

Agreed.

> need documentation of how authorization information is obtained from

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

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 12 Aug 2005 10:50:08 -0700

Hi David,

Please find my reply inline

<snipped>

>to use RADIUS for SSH user authentication?

Most SSH implementations support user/password based authentication
with a RADIUS server and support RADIUS PAP/CHAP/MSCHAPv2. This is pretty
standard RADIUS client behavior.

regards,
   kaushik!

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 12 Aug 2005 14:48:10 -0400

Is there a document already in existence that describes how
to use RADIUS for SSH user authentication? 

Or do we need to write one to document how to get the securityName
information from RADIUS into SNMP? 

Do we need to go read the username from the SSH_MSG_USERAUTH_REQUEST
to populate securityname? Do pretty-standard clients mirror the
User-Name Attribute from the RADIUS Access-Request in the
SSH_MSG_USERAUTH_REQUEST?

Or do we need to go directly read the User-Name Attribute from the
RADIUS Access-Request packet, because pretty-standard clients do not
always mirror this? 

OR do we need to go directly read the User-Name Attribute from the
RADIUS Access-Accept packet, since this MAY be different than the
User-Name Attribute in the RADIUS Access-Request packet? According to
RFC2865, we SHOULD use this if we were doing subsequent accounting
request packets. 

Could we use this capability to provide a user-to-group mapping? Or do
various accounting/business models differ too much from an SNMP access
control model to make reuse of this field problematic?
-

The format of the username MAY be one of several forms:

      text      Consisting only of UTF-8 encoded 10646 [7] characters.

      network access identifier
                A Network Access Identifier as described in RFC 2486
                [8].

      distinguished name
                A name in ASN.1 form used in Public Key authentication
                systems.

Do we need to document the acceptable choices for use with SNMP?

Do we want to support PAP and CHAP and MSCHAPv2? I see CHAP would be
useful for a command-line SNMP application, but what about something
like HPOV where there isn't necessarily a human sitting at the
management application when a scheduled poll occurs? 

Do we need to store the credentials at the management application to
handle scheduled non-human polling, and do we then need to worry about
key distribution to various applications (not to mention the
possibility of somebody finding the credentials in the application
datastore)? Are there pretty standard client approaches for this, for,
say, scheduling CLI script retrieval of device configurations? How are
these issues dealt with? Are these solutions documented somewhere?

David Harrington
[email-masked]

> From: Kaushik Narayan [mailto:[email-masked]] 
> Sent: Friday, August 12, 2005 1:50 PM
> To: [email-masked]
> Cc: 'Sam Hartman'; [email-masked]
> Subject: RE: [Isms] Limited time to charter
> 
> Hi David,
>

---

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

Hi -

> From: "David B Harrington" <[email-masked]>
> To: "'Kaushik Narayan'" <[email-masked]>
> Cc: "'Sam Hartman'" <[email-masked]>; <[email-masked]>
> Sent: Friday, August 12, 2005 11:48 AM
...

Lots of questions deleted
...
> Do we need to document the acceptable choices for use with SNMP?

I believe the answer to this is YES, and that that's one reason why we'd be
doing an applicability statement.

> management application when a scheduled poll occurs?

The operators are said to like scripts.  What do they do?  That should
answer the question, and provide yet another reason for doing an applicability
statement.  There are far too many possible mechanisms; we need to trim the
list down to the ones that we can make work and that will give us the best
coverage of the infrastucture currently in use for management.

> these issues dealt with? Are these solutions documented somewhere?
...

I suspect it will look rather like the "local configuration datastore"  :-)
More seriously, it may be time to think about delegation.  (But not
in this WG!!!!)  We started to look at it in disman, but the general
sentiment of many WG members was that it made their heads hurt
to go beyond the trivial forms we used in the disman MIBs.  (This
was *long* ago.)

Randy

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 12 Aug 2005 14:28:38 -0700

Hi David,

Support for RADIUS authentication for SSH is implementation specific.
Most SSH implementations on Unix including OpenSSH support RADIUS/TACACS+
authentication via a Pluggable Authentication Module (PAM).

http://www.ssh.com/support/documentation/online/ssh/adminguide/32/Pluggable_Authentication_Module__PAM_.html

PAM implementations are available for Linux and Solaris and there are a variety
of supported PAM modules including RADIUS, TACACS+, Kerberos etc.

http://www.kernel.org/pub/linux/libs/pam/modules.html

I believe most SSH implementations on vendor equipment would be similar, i.e
the SSH does not actually integrate with RADIUS, TACACS+ but that is done via
an authentication module.

regards,
   kaushik!

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 15 Aug 2005 15:40:41 +0200

Trimmed even more
Tom Petch

----- Original Message -----
From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>
Sent: Friday, August 12, 2005 9:15 PM
Subject: Re: [Isms] Limited time to charter

> coverage of the infrastucture currently in use for management.

I agree that we need an applicability statement, once we have an I-D specifying
how to integrate SNMPv3 and our chosen Encapsulation Keying protocol.

But ....  we are slotting into a pre-existing environment where we seem to have
little
direct knowledge of which mechanisms are in use.  I keep looking at the
commonest
current system, namely local accounts, and not knowing just what it means.
Plain text passwords manually configured and sent in clear?  I hope not (but
know some enterprises that do just that).  Plain text passwords fed into a
system that generates one time session keys?  ....  I don't know and given the
limited participation of operators in this list do not believe we can reliably
find out.
So I think our applicability statement needs to be catholic, spelling out the
risks of the many different possibilities, rather than prescribing a limited
selection of mechanisms as being the only ones and, in so doing, choosing ones
that are not in widespread use.