Subject: [Isms] RE: Some text on identity and authentication for SSHSM

From: [email-masked]
Date: Sat, 17 Sep 2005 12:17:02 -0700

Hi Juergen,

Please find my reply inline. 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Saturday, September 17, 2005 12:51 AM
To: Kaushik Narayan [[email-masked]]
Cc: [email-masked]; Joseph Salowey [[email-masked]];
[email-masked]
Subject: Re: Some text on identity and authentication for SSHSM

On Fri, Sep 16, 2005 at 07:41:01PM -0700, [email-masked] wrote:
> 
>    1. Each SNMP engine that uses the SSHSM MUST be capable of
performing 
>       the role of SSH server and SSH client and MUST have appropriate 
>       server credentials, i.e. host key pairs are prevelant in most 
>       deployments but may not required in case GSSAPI is used for SSH
key
>       exchange. X.509 certificates will be supported in the near 
> future
> 
>    2. SSHSM will support public key authentication (X.509 certs will
be 
>       supported in the near future for SSH user authentication) and 
>       password based authentication that could be used to support
Local 
>       Accounts, RADIUS and TACACS+ mechanisms.
> 
>    3. Host based authentication (hosts.equiv) MUST not be supported.
> 
>    4. In case host key pairs, each SNMP engine must be pre-configured
with 
>       SSH host public keys of other SNMP engines that it would require
to 
>       communicate (2*) with. 
> 
>    5. The username used in the SSH User Authentication Protocol SHOULD
be 
>       the SNMP securityName and in instances that is not the case, 
>       implementations MUST be to able to map the authenticated name
(3*) to 
>       securityName. 

I am not sure what the purpose of this is. RFC 3411 already requires
that whatever a security model authenticates must map to a securityName.
I am also not sure about the SHOULD. In fact, I have no clue whether you
write requirements, applicability text, security considerations or
protocol specification.

<Kaushik>

The purpose of this text is not to state that RFC3411 allows mapping of
an authenticated name to a securityName but to identify the information
from the SSH transport that will be mapped to the securityName. There
could be a direct mapping of the username in the SSH User Authentication
protocol or mapping between the SSH user identity or host identity to
the securityName. Do you believe that this is implicit and this text is
not required.

I intended to specify requirements in this section.

</Kaushik>

>    1* The use of the SNMP engine in key localization does not really 
>       constitute use of host identity.
>    2* SSH public keys might already be cached on workstations that use
SSH
>       for remote login purposes.
>    3* Some implementations may map host identity to the securityName.
>      
>    Public Key Authentication
> 
>    The SSH authentication method name "publickey" will be used to
support
>    this mechanism. The user's public key and a signature generated
using 
>    the user's private key is sent to the server to authenticate the
user.
>    Although this authentication mechanism is mandatory for the SSH
User
>    Authentication protocol, the use of this mechanisms for SSHSM will
be
>    restricted to operators that use public key authentication when
managing
>    networks via the Command Line Interface (using SSH remote login).

I am only allows to use SSHSM with public keys if I also use them for
the CLI? I fail to see the purpose of this CLR.

<Kaushik>

I think this text is not very clear. Fundamentally without X.509
certificate support for user authentication you would need
identity/public keys to be manually provisioned on SNMP engines (that
act SSH servers)to authenticate requests that use the "publickey"
method, i.e. agents will need to be provisioned identity/public key in
order to authenticate managers that might use publickey method of SSH
user authentication. If these keys are not already provisioned to be
used by NetConf/CLI (over SSH), then having to provision these keys for
use within SNMP actually has the same issues as SNMPv3/USM. The text
intends to state that without X.509 support, the "publickey" method of
SSH user authentication is not preferred unless it is already in  use by
other management protocols such as NetConf that use SSH transport.

</Kaushik>

>    Password based authentication
> 
>    The SSH TMSM will support a variety of authentication systems via
the 
>    SSH user authentication "password" method. The most prevelant would
>    be authentication via RADIUS and Local Accounts. The SSH
authentication
>    protocol will not differentiate between these various mechansims
and will
>    behave identically. Most SSH implementations use a pluggable 
>    authentication mechanism (PAM) for the integration of the password
>    based authentication method to a variety of authentication 
>    systems. 
> 
>    RADIUS Authentication
> 
>    SSHSM SHOULD use RADIUS Digest for authentication for security
reasons. 
>    Implementations MAY however choose to use of RADIUS PAP to support 
>    additional backend authentication systems such as Active Directory
and 
>    Token Servers.
> 
>    The RADIUS server MAY return authorization information such as a
GroupName
>    or Role Name on sucessful authentication. 

The last paragraph, if included, should be phrased in terms of generic
AAA services.

<Kaushik> I think that is fair. I will work on updating the text.

Regards,
  kaushik!

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen,
Germany

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 20 Sep 2005 23:21:24 +0200

> other management protocols such as NetConf that use SSH transport.

I believe the document should specify how the SSHSM works but not
include best current practice usage guidelines or applicability
statements. I have the feeling that we currently mix all these things
together. There might be operators who find it easier to administrate
SSH public keys compared to SNMPv3/USM keys and I believe we should
let operators make such decisions. So I am fine with a statement that
highlights that SNMP over SSH can leverage keys installed for other
management purposes - I dislike statements which say "you should not
use SNMP over SSH if you have to install public keys for this purpose
and no other management access mechanism. The later sounds like a CLR
to me.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany