so first of all I don't know how many people were here last year and heard me
give this talk or give a previous version of this talk okay a couple
all right good I'm glad most of you weren't here because things haven't
changed and improved quite as much as I would have hoped but that's okay what's
more important than ISOC my ISOC connection here is I have been the chair
of the NTP working group for a number of years and I'm also the chair of the
co-chair of the IEEE 1588 Security Subcommittee so let's just go ahead and
get started so the first thing it probably goes without saying that
accurate time needs good security for a long time the time community didn't
really believe this and then in the last number of years we've seen a number of
things that have proved otherwise along those lines performance has always been
the time community's key motivator we need precise accurate synchronized
clocks and you know time information is not secret so why why do we really care
it turns out where you get your time from and if it's been modified in
transit a number of these things actually turn out to be pretty important
the corollary to that actually turns out that good security also needs
accurate time and there's a number of security protocols out there that
actually depend on the fact that the clock is synchronized and you're
beginning to see solutions come out from a number of different places that
actually are sort of bypassing the time synchronization protocols that are out
there to sort of get that initial value of time from some sort of proven and
reliable time source so as I've already said security has not really been
a high priority for the time synchronization community in a long time
but a number of things have specifically changed I think over the last few years
at least the time that I've spent looking at this area first of all
there's a lot more interconnection and decentralization also we're seeing
increasing evidence of the impact of inadequate security the inner dependency
between security and time and then also it turns out legal and compliance
requirements one of the key people that's really been sort of pushing me to
try and get this done has a number of legal issues that would they
would like to see and the only time I've actually ever been called by somebody as
a potential witness in a case had to do with time synchronization and security
which fortunately I was unable to given my job my previous job I was
unable to actually help out in that case something that I was not too terribly
sorry about so first of all as we have seen in the news many many times
attacks are occurring the most notable one are the various ways that NTP can be
used as an amplification attack I'm going to talk about two time
synchronization protocols throughout the course of this presentation
NTP and PTP most NTP is the most widely deployed and it's the one that you're
going to see all of the security attacks on PTP you haven't really seen a lot of
security attacks on yet I think primarily because of where it's deployed
and the scale of its deployment but as we've seen in any number of other
technologies as that scale increases and as the people become more aware of it
then it will also become a target vulnerabilities are constantly being
discovered I don't know how many of you are familiar with the Network Time
Foundation they maintain the NTP code base and in the last year or two talking
to them they have seemed really frazzled about the number of vulnerabilities that
they're getting reported to and a fair amount of frustration about not being
able to get to some of the new and interesting things that we're interested
in working on because they're spending all of their time addressing
vulnerabilities so also research is occurring I'm definitely not an academic
but I can tell you that a number of conferences recently there have been
papers this one actually was from NDSS in San Diego and this one was
specifically dealing with some time issues and there been a number of others
have been published I've seen some published at USENIX and a couple other
conferences this one in particular is going to be presented at the Advanced
Networking Research Workshop that's going to be held in in Montreal in
conjunction with the IETF so all of this research is
occurring and yet after all of this time and after 8 plus years we still have no
new specifications for time synchronization
security and on the one hand I find this terribly frustrating and on the other
hand I feel a tad bit guilty because I have actually been involved in all of
these activities so it is way past time to secure time
there are multiple sources of problems there are flaws in operations so things where the
protocol is configured or implemented in a way that causes issues there are
weaknesses in the NTP protocol itself that can be exploited and then finally
there's the fact that there's there's no adequate security mechanisms built in so
I think a lot of times at least initially when we started looking at the
security problem we were all gung-ho to go to find a security mechanism but a
good portion of the attacks and a good portion of the things that you're seeing
there have don't have a lot to do with whether we authenticate NTP or not they
have a lot to do with the structure of how NTP is built the the way that it's
deployed how it's configured it was originally designed in a world where it
was just a happier friendlier place and we didn't imagine that people would do some
of the evil things they think up these days
so the existing time security specifications for NTP we have
pre-shared keys built in but this mechanism does not scale at all
currently as NIST or USNO actually mails out the keys on a monthly basis to a select
set of clients the auto key specification was developed it was
immediately found to be flawed the IETF security community was not accepting of
it and it was published as an informational RFC with the mandate that
you all will go off and develop a standards track security mechanism for
ntp won't you any day now then IEEE 1588 came along version
1 had no security at all version 2 we specified Annex K which was an
experimental annex and it was published there was some initial testing done on
it and it was proven to be flawed and so now we're in the process of working on
version 3 and it will have a new security solution
now we have talked about requirements and I've often heard people say you spend a lot of time
talking about requirements you need to actually move on to the solution but
we've done a fairly detailed analysis of requirements and this has sort of become
the foundational document to at least be able to define what the
requirements are that are associated with time synchronization protocols in
general so now I'm going to move on to NTP and sort of the status of the time
synchronization security work there so the IETF approach to the problem has
been to look at all three of those areas that I talked about earlier in the flaws
and configuration and implementation of existing protocols in NTP BCP was
developed weaknesses in the protocol itself tweaks and clarifications we're
attempting to get some of those done we've also been sort of talking in the
background about potentially doing an NTP v5 and the lack of adequate security
mechanisms well that's the network time security which I will get to momentarily
so the BCP
fascinating looked at the wrong thing on here so I've actually
already spoken to this slide because I was looking at it over here but you get
the idea so the next one is the to go into a little bit more detail on what
these are the first one is the BCP it was proposed and I went ahead and put up
to give you all some sort of a sense of the timeline the on your right is from
the IETF data tracker so anytime you're interested in the history of a document
if you just go to datatracker IETF org and for every document that is in
process you can find the timeline for it and you can see where it spent more time
and where it spent less time so the BCP has had a lot of community
input and it should be published it has been submitted for publication it
contains a lot of the same information that you will find from any number of
vendors and operators out there that have published best
practices associated with NTP and particularly addressing the
amplification attack for NTP we're also in the process of updating a MAC for NTP
this is a really really short document but basically it says yeah we agree md5
is broken and maybe it's about time for us to replace it and I know that that's
a little bit overdue but that's what we did there the NTP client data
minimization draft was actually brought about by privacy concerns and the linkability
issue that's been brought more to the forefront in recent
years this draft is actually currently expired but we did have some recent
implementation experience with this at the -- there was a hackathon
held at the African Internet Summit a few weeks ago and one of their projects
was to work on an implementation of this so I think you're going to see a quick
resurrection of this draft and a publishing of it it's a very simple
modification to ntp that just clears out some fields that aren't necessarily
needed and finally we get to the NTS draft and I'm really working on a
positive attitude for this draft but I'm struggling a bit it's been quite a
chore to get where we are and we had an initial version that some
researchers from Germany went through and did and they published it or they
didn't publish it we put it out for a working group last call and the
security community just rained all over it asked us why we were reinventing the
wheel and we went back to square one and then we had the second one which we sent
out for working group last call last fall and the time community came back
and said what are you doing are you nuts and so we're now in the middle of
resolving the what are you doing are you nuts process
we as part of that one of
the real challenges with NTP is you have your server client model mode of
service which is a relatively -- there's a number of people who believe that's
the mode that most people really care about it's not the only mode that exists
though NTP also has symmetric modes and a broadcast mode and it turns out that
those are all different models of communication and finding a single
security solution that fits them all is proving to be really difficult so the
current draft which is draft 11 and I actually happened to be speaking to one of
the authors this morning I've been promised a draft 12 any day now and
that draft will -- the most recent few drafts the ones since the working group
last call we have gone in and we have basically agreed to focus this solution
on the server client mode for NTP only and this is a change it means that we're
not solving all of the modes of service for NTP but we figure for the people
that are operating NTP that care about security this would be a good first step
and I'll get to this a little bit later on but I think one of the cycles
that protocol development gets stuck in is the you know at some point you just
need to get something done you need to get something out there and
get it implemented and get experience with it or you're going to be stuck in
forever in this this isn't quite right loop you do run the risk of it being
fatally flawed but it wouldn't be the first thing out there to be fatally
flawed so anyway what does NTS provide integrity for NTP packets unlinkability
provided you're using the data minimization draft I've already talked
about a request response consistency which is to avoid replay attacks
authentication of servers authorization of clients and support for the
client-server mode only and basically as I have said the symmetric and the broadcast
modes have been deferred a caveat emptor
this has not been published yet and last
year I was talking to some people about this and I was convinced that we would
be done by this time this year and we would be talking about implementation
experience but that is not quite the case
so basically NTS is TLS for NTP security what it does is uses TLS to do the key
exchange and then it uses NTP extension fields to secure the packets with the
key that has been exchanged in the TLS handshake and I'm not going to go into
this sort of detail but these are the extension fields that have currently
been defined and they're one -- the proposal for the symmetric modes and the
others was a use of DTLS and so they were looking at TLS for the server
client modes and DTLS for the other modes the key here is the security
community really doesn't want us to go and invent our own security mechanisms
for good reason I think they've watched a lot of people
over the years get it wrong so here we are that's where we are with that and
I'm going to go quickly through IEEE and PTP because this one hasn't really
changed as much oh one other thing before I move on from NTP we do have for
the current draft of NTS we have a couple of proof of concept
implementations I we don't have an implementation that's running in a
deployed codebase yet we did a hackathon in March at the IETF and we're planning
another hackathon at the July IETF meeting and I'm really hoping that we're
going to get a production code base with an implementation in there it doesn't
have to be an implementation it doesn't have to be a production quality
implementation but I want a code base that is operational somewhere to have
this added into it and then we can do interoperability testing we did do
preliminary interoperability testing between the two implementations
that we had in March those two we were able to find some bugs we updated the
spec that's some of the the changes that you'll see in the version 12 which is
coming out any day now and the
I completely lost what I was going to say
oh so there were some some interoperability changes and we were
able to establish interoperability between those two implementations I'm
eager for anybody who was interested as a student that might want to try this
out we have we have lots of implementation opportunities here so
IEEE and PTP so PTP is probably not as big an interest to this community
as NTP but it is the other major time synchronization protocol out there it
does a lot more in in telecom networks in like factory automation type of
networks and also very precision oriented ones if you're interested in
this if you were to look up like White Rabbit for example White Rabbit is what
CERN is using to synchronize some of their components so in 1588 we defined a
multi-pronged approach where Prong A is to build security mechanisms that would
work with PTP then Prong B is to define external security mechanisms that might
be in place that we could use Prong C is to look at architectural mechanisms to
improve the security of the system and that was primarily redundancy and Prong
D is for monitoring and management and how you can use that to improve the
security of your system getting back to the whole point that it's not just about
the security protocol that's built
into those time synchronization
protocols it's really about the whole architecture and the infrastructure
that's around that so I'm not going to go into a lot of detail on PTP because I
do want to leave a few minutes for questions but so this
the point I'm getting to now is the Prong A piece which is the if you're going to
add security to a PTP packet this is how you do it so this is the modification
to the PTP packet to support security what you'll see here is some
authentication TLVs one that's called delayed processing and one that's called
immediate processing and then we have -- 1588 has the concept of TLVs and
there is a security TLV or a set of security TLVs that have been defined for
use with 1588 and so this is the the framework of the TLV I know you are
all going to study this quite deeply this is the PTP packet processing if
your and basically this says does it or does it not have a security TLV and
what you do with it and then this is the security process of course it's longer
and more detailed than the previous one if you ever been involved in the
IEEE standards processes and the IETF standards processes they're
completely different and then there's key management well so
what we have key management is always the tough problem so we have static key
management for -- static key management will make what currently is existing in
the specification work but of course again it's not scalable and then we have
what we're calling instant key sharing and delayed key sharing for GDOI and
for TESLA and this is basically the difference between are you willing to
trust the time information initially before you verify the security or are
you going to wait until you have verified the security before you use
the time information different environments will choose different
models one of the key differences between PTP and NTP is PTP has polling
intervals that are much much faster generally than NTP so NTP has come from
the perspective of a global Internet so it's doing things to reduce the polling
interval whereas PTP goes the opposite direction and it's like we you know send
as many packets as possible if you look at the IEEE 802.1 AS
specification which is essentially a profile of IEEE 1588
the polling intervals are much much higher than you would see an
NTP so in any event there's these two key sharing mechanisms since --
know the only thing that's actually normative in 1588 is the specification of the TLV and
how its processed and all of the rest of it is left to the informative which is
sort of the IEEE way of saying we're going to deal with that hard
problem a little bit later on to really have an implementable
solution with GDOI and TESLA is going to require some additional work
and some of this is going to need to be done in the IETF so there's instant key
sharing and there's delayed key sharing the external transport
mechanisms are MACsec and IPsec architecture guidance monitoring and
management best practices I've already talked about how am i doing on time
pretty close so final remarks um I really believe the time is now and I say
this because I think that we've been you know in the last week and a half I've
gotten an email from somebody who I knew is working in this area
who was like you know we're really interested in this we're ready to jump on
board now but we think what you've got is wrong and we have some proposals on
how to change it I have additional conversations with some other folks that have
been involved in the effort and they're like well we really think that this is
the wrong thing and we're going to redo the whole thing from scratch and a
proposal is coming any day now I think at some point you got to move forward
and I think now is the time to move forward so any implementers testers and
researchers are welcome especially somebody who has an outside perspective
that can help encourage the now a little bit now is better than the perfect
solution later and my motto for this whole activity at the moment is done is
better than perfect contact me if you're interested in helping I'd
love to have some things help acknowledgement and thanks I'm not going
to go through these but the paper that I uploaded when I put in this submission
was co-authored by Stefan Fries and Diieter Sibold Stefan has been the
primary driver of the GDOI solution and Dieter has been the primary driver of the
TESLA solution they aren't the reason why we have two solutions in 1588
they're the ones who help specify both solutions when the group couldn't decide
which one was the one they wanted to go with
and so finally any questions
[applause]
all right if you all don't have any questions feel free to contact me at any
point my slides will eventually be online I'm very sorry they aren't there
yet but they will be soon Thanks
[applause]
Không có nhận xét nào:
Đăng nhận xét