Re: [Isms] Question regarding RFC 6353

[Kenneth Vaughn <[e-mail]>]

Tom et al.

Thank you for this great information. We will continue to study this topic and will present the information to the corresponding transportation WGs to decide on our future direction. 

To give you some background, within the US, the Intelligent Transportation Systems (ITS) industry adopted the use of SNMPv1 in the late 1990s for managing an array of field devices (signal controllers, ramp meters, message signs, etc.). We have standardized the data for these devices (and some other issues) under the National Transportation Communications for ITS Protocol (NTCIP), which is a joint effort among the American Association of State Highway and Transportation Officials (AASHTO), the Institute of Transportation Engineers (ITE), and the National Electrical Manufacturers Association (NEMA). 

Around the same time, the UK adopted SNMP (v2) to manage some of their field devices using a separate set of MIBs (under their UTMC project). 

Over the years, the US and UK solutions have been almost universally adopted within those two countries while also being widely deployed in other countries. 

From the beginning, I have been complaining about the lack of security in these standards, but SNMPv3 was not released until the early 2000’s after deployments had already started and there was little interest within the industry to revisit a decision when most networks at the time were private networks and many of the links were extremely slow (e.g., 1200 bps to the field - this even led to the development of a much more bandwidth friendly version of SNMP that is specific to ITS). However, there is now increased interest in securing the protocol due to:
- Higher speed communication networks - often shared 
- Higher speed processors in field equipment that run modern operating systems (e.g., Linux)
- Increased cybersecurity threats - and a few attacks that have impacted operations in specific areas
- The need to prepare for connected vehicles in the relatively near future.

Within the last decade, I have been involved in the development of two ISO TC 204 standards to address this issue (ISO 15784-2 defining how to use SNMP - including SNMPv3 - within ITS and ISO 20684 (all parts), which defines standardized data for devices).

After twenty years, the US is now accepting that we need to secure our protocol and is undertaking the current study to investigate the best way to achieve this. My best guess at this point is that the WG will decide to maintain the path towards using SNMPv3. It seems to me that the way in which we use the protocol is somewhat different than traditional network management. Based on my review of various articles, it seems as if the network management industry was (and still is) happy to use SNMP for network monitoring potentially with very basic security - but migrated to NETCONF for the purposes of device configuration, which tends to be a very manual process.  Within ITS, we use SNMP for both of these purposes but also use it for automated command and control on a fairly regular basis (e.g., altering signal timing, changing a message on a sign, etc). And the majority of our configuration commands are often just minor tweaks to a rather massive amount of information in the device. Thus, my impression of NETCONF and even RESTCONF with JSON is that they would entail a significant change in logic within our systems coupled with an increase in bandwidth and processing utilization while not providing any real practical benefit for our industry - except for the odd case of the complete (or substantial) controller re-configuration process - which is fairly rare. If you think I have somehow mis-characterized the impacts of NETCONF/RESTCONF, I am happy to be corrected, but assuming that my analysis is correct, I think our industry would prefer to continue the use of SNMP - or perhaps migrate to a completely different solution, in particular there would be some advantages to using data distribution technologies such as AMQP, MQTT, Kafka, or DDS but these obviously have very different trade-offs offering much better monitoring and data sharing while not handling the command and control as well.

I will keep you posted as the project progresses, but I suspect that there will likely be real interest within our industry to make sure that the security for SNMPv3 is maintained and updated to work with TLSv1.3. While I understand that the efforts to produce this type of documentation might have to depend heavily on ITS support, I would certainly hope that any such maintenance can be performed under the auspices of IETF so that other users of SNMPv3 can directly benefit from these efforts (e.g., rather than developing this update as an ISO or NTCIP standard where most of my involvement has been to date on this topic).

NOTE: As an aside, there might also be interest within the ITS community to add support for SNMPv3 using IEEE 1609.2 certs rather than just X.509 certs (https://datatracker.ietf.org/doc/draft-msahli-ise-ieee1609/), but this is likely a longer-term issue and obviously has to await feedback from the relevant ITS committees.

Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
[phone]
[phone] cell
www.trevilon.com

> On Jul 22, 2020, at 4:40 AM, tom petch <[e-mail]> wrote:
> 
> From: Wes Hardaker <[e-mail]>
> Sent: 21 July 2020 23:46
> tom petch <[e-mail]> writes:
> 
>> I think that it may be more complicated than that.  TLS 1.3 is a
>> radical restructuring of TLS so that e.g. the concept of a ciphersuite
>> changes, digital signatures are specified separately and while
>> renegotiation has gone, TLS has never been much of a fan of client
>> authentication which SNMP is fussy about and prohibited renegotiation
>> as a result.
> 
> I think client-based certificate authentication is the only thing that
> would prevent RFC6353 from working over TLS 1.3, and I doubt it'll be a
> problem (but haven't done the work to prove it).  RFC6353 was explicitly
> written to not specify one specific version of TLS to use.  The only
> thing it states authoritatively is in 9.2.1:
> 
>   Because of known security vulnerabilities,
>   TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0.
>   See Appendix E.2 of [RFC5246] for further details.
> 
> The reference to TLS 1.2 via RFC5246 is in the document because we had
> to normatively reference *some* version of TLS, and that's what was
> available then.  No where in the document does it say "that's the only
> version you should use".
> 
> <tp>
> Yes, my concern is more one of Fear, Uncertainty and Doubt as opposed to hard engineering, but this is security so it behoves us to be cautious.  I see many strands
> 
> Security is about operational practices and
> draft-ietf-opsec-ns-impact
> looks at what may be difficult or impractical with TLS 1.3 compared to
> TLS 1.2.  Note that it is an I-D and it might be a year or two before
> the IETF gets to decide whether or not to publish it as an RFC by which
> time all sorts of things might have happened.  The issues in the I-D have
> appeared on the TLS WG list and been rejected.  The I-D was proposed for
> adoption by the TLS WG and was rejected although it did get some review
> and constructive feedback, that is, its description of the behaviour of TLS1.3 has been reviewed.
> I commend that I-D to anyone looking to migrate to TLS1.3 who has anything more than
> an HTTP web server.
> 
> Part of the ethos of the TLS WG is that where there is a conflict
> between the security of an individual and that of an organisation then
> the former takes precedence which I see as relevant here.
> 
> TLS, like SSL before it, has little concern with the authentication of
> the user, that often being done with renegotiation.  For OAM in general,
> and SNMP in particular, user authentication is paramount; the protocol
> must yield an authenticated identity.  Given the major reconstruction of
> TLS with 1.3, I would not assume that the user identity is ok without a
> careful study.  SNMP prohibited renegotiation as TLS1.3 has done for
> different reasons.  The TLS WG has just approved an I-D
> draft-ietf-tls-exported-authenticator
> which offers a replacement for renegotiation; is that ok for SNMP?
> probably not. The approach to signature schemes has changed in TLS 1.3;
> is there any impact on user certificate chains?  Much of the work on
> TLS1.3 was on facilitating 0-RTT; is that ok?  I think that given
> security is involved, then TLS 1.3 and all the TLS1.3 extensions need
> careful examination from the perspective of delivering an authenticated
> user identity before I would regard it as... well, not safe, because I
> never say anything is safe but rather without any risk that I can see.
> 
> My background is operations, not security, so I have a 101 understanding
> of security and TLS (but will never be a cryptographer:-)
> 
> HTH
> 
> Tom Petch
> --
> Wes Hardaker
> USC/ISI
>