[Isms] SSH tunneling and SNMPv3

["David B Harrington" <[e-mail]>]

Hi Martin,
 
It is important to identify, preferably using SecSH terms and
references, just what "SSH tunneling" means.

SecSh Transport Layer Protocol provides authentication, integrity
checking, and encryption.
from draft-ietf-secsh-transport-22.txt: "Authentication in this
protocol level is host-based; this protocol does not perform user
authentication.  A higher level protocol for user authentication can
be designed on top of this protocol." SNMPv3 is designed to provide
per-user controlled access to data, so host authentication is
inadequate to meet the design goals for SNMPv3 (that were established
by IETF consensus).  

The SecSH Authentication Protocol (draft-ietf-secsh-userauth-25.txt)
provides user authentication, and that comes closer to meeting SNMPv3
per-user requirements. However, it is necessary to have a binding
between the user authentication of SecSH and the user identity used
for per-user access control. I could use SecSH authentication to
establish a session for user "dbh", and then pass an SNMPv1 message
claiming rights to the "super-user" community (or an SNMPv3 message
claiming a USM identity of "super-user" rather than dbh). There needs
to be a binding between the authentication of the user and the
application of access permissions for that user. So either SecSH needs
to be pass the authenticated user identity to the SNMP engine so SNMP
can apply appropriate access control, or SNMP has to perform its own
user authentication independent of SecSH.

Also, SNMPv3 provides a wealth of features beyond authentication and
privacy that are important to some, but not all, environments. I won't
go into them here, because that is not within the scope of this WG. I
leave it to you to understand the benefits of engineID,
contextEngineID, a standardized proxy, a standardized notification
addressing mechanism, a standardized notification filtering mechanism,
etc.

David Harrington
[e-mail]
________________________________

	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Martin Soukup
	Sent: Friday, February 18, 2005 4:07 AM
	To: 'Wes Hardaker'; [e-mail]
	Subject: RE: [Isms] achieving market saturation with ISMS
	
	

	Wes, 

	My understanding of the evaluation report was that there were
two mandatory-to-implement mechanisms, one implicit and the other
explicit. The explicit mechanism was in fact RADIUS but I believe the
support of local accounts was implicitly required as well (where the
device acts as a RADIUS key distributor) for clients connecting to it.
Perhaps the evaluation team can confirm?

	I don't feel that those using SSH tunnelling require SNMPv3
(since SSH provides authentication and privacy), so I'm not sure where
that combination comes from. Could you explain that?

	I agree with Wes' point that the result of this effort should
be careful to address the requirement to make SNMPv3 deployment easy
in existing deployments but I would note that from this survey it
would appear that RADIUS is the market leader for centralized AAA, we
just need to be sure to support non-centralized AAA as well. I think
most of the people on the list have been saying this all along.

	Martin. 

	> -----Original Message----- 
	> From: [e-mail]
[mailto:[e-mail]] On 
	> Behalf Of Wes Hardaker 
	> Sent: February 18, 2005 12:22 AM 
	> To: [e-mail] 
	> Subject: [Isms] achieving market saturation with ISMS 
	> 
	> 
	> One of the whole reasons behind David and my efforts to get
this work 
	> under way within the IETF was to try and help the operators
with 
	> deployed authentication infrastructures (of any type) to be
able to 
	> access their devices securely over SNMPv3 using identical 
	> authentication mechanisms.  The most critical problem with
deploying 
	> SNMPv3 wasn't that it wasn't better than v1/v2c but that it
was hard 
	> to deploy due the maintenance it required.  This is, of
course, 
	> already known. 
	> 
	> When we approached the IESG about starting a working group,
we were 
	> asked to prove that people needed such a change and this was
the 
	> reason many people weren't using SNMPv3 in the first place.
To do 
	> this, we offered a survey and advertised it to NANOG and a
few other 
	> places.  We got 149 responses.  Some of the questions that
were asked 
	> had surprising results, some were expected. 
	> 
	> To recap some of the important things to consider as this
work goes 
	> forward: 
	> 
	> 26% of the people that responded used SNMPv3 at that time. 
	> 
	> Of the various authentication systems in use at that time by
the 
	> people that responded: 
	> 
	>   66%  local accounts 
	>   49%  SSH-keys 
	>   40%  Radius 
	>   29%  TACACS+ 
	>   14%  X.509 Certificates 
	>   10%  Kerberos 
	> 
	>   [numbers don't add to 100 because more than one option
could be 
	> selected] 
	> 
	> This result set actually surprised me.  I knew that SSH was
popular as 
	> was local accounts, but I actually expected Radius to be in
greater 
	> use than it was.  40% is certainly heavy usage, but it is
hardly 
	> market dominance. 
	> 
	> One of the reasons that I've told many people that I'd be
happy with a 
	> transport based solution, such as the TLSM solution had
offered, even 
	> though it wasn't my number one choice, was that it would at
least meet 
	> the criteria of getting the largest percentage of deployment

	> possible.  Specifically, it would be easy to make it work
with both 
	> local accounts over a TLS tunnel as well as SSH based
identities over 
	> a SSH tunnel.  Thus, it would likely have a huge impact on
the 
	> usability of SNMPv3. 
	> 
	> Where I'm going with all of this is that I disagree with
section 
	> 3.2 that states: 
	> 
	>    The evaluation team also recommends, in the interest of 
	>    interoperability, that the working group select a single 
	>    mandatory-to-implement mechanism.  The evaluation team
recommends 
	>    RADIUS [RFC2865] for this purpose, due to its widespread
use. 
	> 
	> If you offered operators a solution which was couched around
Radius 
	> and they didn't use it, you wouldn't be offering them
anything.  It's 
	> somewhat akin to saying "Ok, we learned that you didn't like
SNMPv3 
	> because you didn't want to maintain another infrastructure.
We've now 
	> fixed that, here install this different infrastructure
(Radius) instead." 
	> 
	> We've already seen the ramifications of selecting an
authentication 
	> system which people didn't want to use.  I don't think that
if you 
	> selected Radius as a mandatory to implement protocol that
you would 
	> much greater than 40% saturation with it, which in my
opinion is way 
	> too low.  As much as the security side of me hates to say
it, I think 
	> we should strongly consider making local accounts the
mandatory to 
	> implement form because that is simply what is in use the
most. 
	> 
	> Even worse, if EUSM-like is the path chosen it requires that
Radius or 
	> any other protocol be modified before it could be used by
this 
	> architecture.  That's a rather important point, so I'll
restate it. 
	> The other protocols must be modified before they'll work.
It's 
	> important because it means the current deployed base of the
modified 
	> protocol is 0%.  It means that even if you shipped the
solution today, 
	> everyone would have to upgrade their infrastructure or
install new 
	> infrastructures in order to make the solution work.  That,
to me, is 
	> not giving the operators what they've been asking for: to
make SNMPv3 
	> work with what they have today. 
	> 
	> -- 
	> Wes Hardaker 
	> Sparta 
	> 
	> _______________________________________________ 
	> Isms mailing list 
	> [e-mail] 
	> https://www1.ietf.org/mailman/listinfo/isms 




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