Serviço NTP
Autor: Experiencias Vividas | Publicado: 2013-09-30T13:29:00-07:00

FONTE:&nbsp;http://www.ntp.br/NTP/MenuNTPNtp 

As mensagens do NTP são baseadas no protocolo UDP, que é um protocolo não confiável e não orientado à conexão.


A troca de mensagens entre cliente e servidor permite que o cliente descubra qual seu deslocamento (offset) em relação ao servidor, ou seja, o quanto seu relógio local difere do relógio do servidor.


Consideremos servidor e cliente com relógios não sincronizados. A troca de mensagens, ilustrada na Figura 3, dá-se da seguinte forma:

 

 O Cliente lê seu relógio, que fornece o tempo a.

 O Cliente envia a Mensagem 1 com a informação de tempo a para o servidor.

 O Servidor recebe a Mensagem 1 e nesse instante lê seu relógio, que fornece o instante x. O Servidor mantém a e x em variáveis.

 O Servidor após algum tempo lê novamente seu relógio, que fornece o instante y.

 O Servidor envia a Mensagem 2 com a, x e y para o cliente.

 O Cliente recebe a Mensagem 2 e nesse instante lê seu relógio, que fornece o instante b.





Figura 3: Troca de mensagens (1)
Ao receber a Mensagem 2, o Cliente passa a conhecer os instantes a, x, y e b. Mas a e b estão numa escala de tempo, enquanto x e y em outra. O valor do incremento dessas escalas é o mesmo, mas os relógios não estão sincronizados.


Não é possível, então, calcular o tempo que a Mensagem 1 levou para ser transmitida (T-ida), nem o tempo que a Mensagem 2 gastou na rede (T-volta). Contudo, o tempo total de ida e volta, ou atraso (também conhecido por Round Trip Time ou RTT) que é a soma T-ida + T-volta pode ser calculado como:


atraso (delay) =  (b-a)-(y-x). 
Considerando-se que o tempo de ida é igual ao tempo de volta, pode-se 
calcular o deslocamento entre o servidor e o relógio local como como:


deslocamento (offset) = x - (a + atraso/2) =  
deslocamento (offset) = (x-a+y-b)/2. 
Para facilitar a compreensão, considere-se o seguinte exemplo numérico.

 

 O Cliente lê o relógio: a=9.

 O Cliente envia a Mensagem 1 (a=9).

 O Servidor recebe a Mensagem 1 (a=9) e lê seu relógio: x=4.

 O Servidor algum tempo depois lê seu relógio novamente: y=9.

 O Servidor envia a Mensagem 2 (a=9, x=4, y=9).

 O Cliente recebe a Mensagem 2 (a=9, x=4, y=9) e lê seu relógio: b=18.





Figura 4: Troca de mensagens - exemplo (1)
Ao olhar a Figura 4, é fácil observar que T-ida=2 e T-volta=2. Contudo, nem o Cliente nem o Servidor têm essa visão. O Servidor ao final da troca de mensagens descarta todas as informações sobre a mesma. O Cliente conhece as variáveis a=9, x=4, y=9 e b=18, mas à partir delas é impossível calcular T-ida ou T-volta. Contudo, é possível calcular o atraso e o deslocamento:


atraso = (b-a)-(y-x) = (18-9)-(9-4) = 9 - 5 = 4.   
deslocamento = (x-a+y-b)/2 = (4-9+9-18)/2 = -14/2 = -7. 
Um deslocamento de -7 significa que o relógio local do Cliente deve ser atrasado 7 unidades de tempo para se igualar ao do Servidor.


Note-se que foi assumido alguns parágrafos acima, para se conseguir calcular o deslocamento, que T-ida = T-volta. Mas isso nem sempre é verdade!
 Há atrasos estocásticos nas redes devido às filas dos roteadores e 
switchs. Numa WAN ou na Internet enlaces de diferentes velocidades e 
roteamento assimétrico, além de outros fatores, também causam diferenças
 entre T-ida e T-volta.  


No entanto o NTP funciona exatamente dessa forma, considerando que T-ida = T-volta.


Isso implica num erro. Esse erro, representado na Figura 5, é no pior caso igual à metade do atraso. Ou seja:


deslocamento - atraso/2 &lt;= deslocamento verdadeiro &lt;= deslocamento + atraso/2 



Figura 5: Erro do deslocamento por causa da assimetria
Tome-se o seguinte exemplo numérico, ilustrando o pior caso. Os servidores são os mesmos da Figura 4, mas a primeira mensagem leva um tempo desprezível pra ser enviada, enquanto a segunda demora 4 unidades de tempo: a=9; x=2; y=7; b=18.  Nesse caso T-ida=0 e T-volta=4. O exemplo está ilustrado na Figura 6.




Figura 6: Troca de mensagens - assimetria (1)
Calcula-se o atraso como:


atraso = (b-a)-(y-x) = (18-9)-(7-2) = 9 - 5 = 4.   
deslocamento = (x-a+y-b)/2 = (2-9+7-18)/2 = -18/2 = -9. 
O deslocamento está errado! Sabe-se que o valor correto é -7, contudo o 
valor calculado é -9. Isso deve-se a assimetria da rede, no tocante a 
T-ida e T-volta.

No entanto, à partir do cálculo do deslocamento e do atraso, e levando 
em conta a limitação do método, que considera T-ida=T-volta, sabe-se que
 o deslocamente verdadeiro está entre:


deslocamento - 2 &lt;= deslocamento verdadeiro &lt;= deslocamento + 2
  
-9 -2 &lt;= deslocamento verdadeiro &lt;= -9 + 2
  
-11 &lt;= deslocamento verdadeiro &lt;= -7

Ou seja, dado um deslocamento de -9 e um atraso de 4, sabe-se que o 
valor verdadeiro do deslocamento é algo entre -11 e -7, mas não há como 
ter certeza de qual o valor. Como nesse exemplo o valor correto é 
conhecido de antemão, -7, pode-se verificar que o cálculo funciona 
adequadamente.

Voltar


 O Algorítmo de Filtro de Relógio 
Através da troca de mensagens, o NTP consegue as informações de atraso e
 deslocamento de um servidor. Essa troca de mensagens não é realizada 
uma única vez. Ela se repete periodicamente, com o período dinamicamente
 controlado pelo NTP.


No início da sincronização o cliente NTP faz uma consulta a cada 
servidor a cada 64s. Esse período varia ao longo do tempo, geralmente 
aumenta, até chegar a 1024s (aproximadamente 17min). As variáveis minpoll e maxpoll definem o mínimo e o máximo, e são representadas em potência de 2. Ou seja, por padrão minpoll = 6 (26=64) e maxpoll = 10 (210=1024). Numa consulta à lista de servidores NTP, a variável poll representa o período e a variável when é um contador que indica quantos segundos se passaram desde a última consulta; quando poll = when uma nova consulta é realizada e a variável when é zerada. Se o parâmetro iburst
 é utilizado na configuração de um servidor, a taxa de envio de pacotes é
 acelerada no início da sincronização, de forma a se conseguir um 
conjunto de dados mais depressa. A variável reach 
representa um registrador de deslocamento de 8 bits, cujo valor é 
mostrado no formato octal. Um bit 1 significa que o cliente obteve 
resposta do servidor para uma consulta. Então o valor 377 = 11.111.111, 
significa que as últimas 8 consultas ao servidor foram bem sucedidas.



       usuario@servidor:~$ ntpq -c pe
         remote     refid    st   t when poll reach   delay   offset  jitter
       ======================================================================
       *servidor1   .IRIG.    1   u   93  128  377    0.523    0.020   0.033
       +servidor2   .GPS.     1   u   57  128  377    0.488   -0.054   0.025
       -servidor3   .IRIG.    1   u   50  128  377    5.151   -0.386   0.382
       +servidor4   .IRIG.    1   u   34   64  377    5.163   -0.360   0.559




Figura 7

É importante notar então, que não há apenas um valor de atraso e um de 
deslocamento para cada servidor, mas um conjunto deles, provenientes das
 diversas trocas de mensagem! A partir dessa lista de valores, o Algorítmo de Filtro de Relógio calcula então um valor de atraso (delay), de deslocamento (offset) e de variação (jitter).


Na verdade, cada amostra é composta de 4 valores: atraso, deslocamento, 
dispersão e estampa de tempo. A estampa de tempo indica quando a amostra
 chegou. A dispersão é o erro estimado do relógio de servidor remoto, 
informada pelo servidor na mensagem NTP.


A lista com os valores é ordenada em função do atraso. Considera-se que 
as amostras com menor atraso são melhores porque provavelmente não se 
sujeitaram a filas nos switches e roteadores, de forma que 
parte das variações estocásticas de tempo no envio e recebimento das 
mensagens é evitada com essa escolha.


Os valores mais antigos são descartados, porque o valor de deslocamento 
pode não mais corresponder à realidade, já que a exatidão do relógio 
local varia ao longo do tempo.


Após descartar as amostras antigas, resta uma lista com as amostras mais
 recentes e ordenadas em função do atraso. Da primeira entrada dessa 
lista são retiradas as variáveis atraso e deslocamento para o par 
cliente servidor (note-se que para cada par cliente - servidor há uma 
variável de cada tipo).


A dispersão e a variação são calculadas levando em conta todos os valores da lista.


A Figura 7 ilustra o funcionamento desse algorítmo.


Os valores para cada servidor associado podem ser consultados no NTP como segue:



       usuario@cliente.local:~$ ntpq
       ntpq&gt; pe
         remote     refid    st   t when poll reach   delay   offset  jitter
       ======================================================================
       -servidor1   .IRIG.    1   u    8   32  377    0.407    0.248   0.016
       -servidor2   .GPS.     1   u    -   32  377    0.474    0.213   0.019
       +servidor3   .GPS.     1   u    9   64  377   15.680   -0.005   0.026
       +servidor4   .IRIG.    1   u   30   64  377   15.582    0.004   0.100
       *servidor5   .GPS.     1   u   10   32  377    0.400   -0.026   0.049
       xservidor6   .IRIG.    1   u   26   64  377    7.824    9.923   0.367
        servidor7   .INIT.   16   u    - 1024    0    0.000    0.000 4000.00
       -servidor8   .ACTS.    1   u   13   64  377  202.274    2.459   0.309
        LOCAL(0)   LOCAL(0)  13   l   48   64  377    0.000    0.000   0.001

Detalhando os valores para o primeiro (&amp;1) servidor da lista:



       ntpq&gt; rv &amp;1
       assID=47012 status=9314 reach, conf, sel_outlyer, 1 event, event_reach,
       srcadr=servidor1, srcport=123, dstadr=cliente.local, dstport=123,
       leap=00, stratum=1, precision=-19, rootdelay=0.000,
       rootdispersion=0.351, refid=IRIG, reach=377, unreach=0, hmode=3,
       pmode=4, hpoll=5, ppoll=5, flash=00 ok, keyid=0, ttl=0, offset=0.248,
       delay=0.407, dispersion=0.059, jitter=0.016,
       reftime=cacb6721.f903866e  Thu, Oct 25 2007 17:04:01.972,
       org=cacb6729.1e5c8d02  Thu, Oct 25 2007 17:04:09.118,
       rec=cacb6729.1e5a1448  Thu, Oct 25 2007 17:04:09.118,
       xmt=cacb6729.1e393ee5  Thu, Oct 25 2007 17:04:09.118,
       filtdelay=     0.44    0.41    0.56    0.56    0.58    0.54    0.58    0.53,
       filtoffset=    0.26    0.25    0.23    0.27    0.26    0.22    0.24    0.25,
       filtdisp=      0.00    0.03    0.06    0.09    0.12    0.15    0.18    0.21


Voltar


 O Algorítimo de Seleção dos Relógios 
Uma vez que o Algorítmo de Filtro de Relógios tenha calculado os 
principais parâmetros referentes a cada servidor, faz-se importante 
descobrir quais deles são confiáveis e quais não. Os servidores que têm 
algum erro no tempo fornecido são chamados de relógios falsos (falsetickers, na literatura em inglês, a tradução é aproximada). Os servidores que fornecem a hora corretamente são chamados de relógios verdadeiros (truechimmers, em inglês, uma tradução mais literal seria algo como "badaladores verdadeiros").


Para a seleção dos relógios, o NTP considera como verdadeiro o deslocamento que se encontra dentro de um determinado intervalo de confiança, representado na Figura 8. Esse intervalo é calculado, para cada associação com um servidor, como:


intervalo de confiança = (deslocamento/2) + dispersão. 



Figura 8
A Seleção de relógios busca um intervalo de intersecção
 para os valores de deslocamento de cada servidor, considerados os 
intervalos de confiança. Os servidores cujos deslocamentos ficam fora da
 intersecção são relógios falsos. A Figura 9 ilustra isso para 4 servidores, A, B e C são relógios verdadeiros, e D é um relógio falso:




Figura 9
Ao consultar-se a lista de servidores do NTP, os relógios falsos são 
identificados por um "x". No exemplo abaixo, o servidor6 é um relógio falso (esses símbolos, como o "x", usados para diferenciar os servidores, são chamados de tally-codes, para mais detalhes deve-se consultar a seção Utilizando.):



       usuario@cliente.local:~$ ntpq 
       ntpq&gt; pe
         remote     refid    st   t when poll reach   delay   offset  jitter
       ======================================================================
       -servidor1   .IRIG.    1   u    8   32  377   0.407    0.248   0.016
       -servidor2   .GPS.     1   u    -   32  377   0.474    0.213   0.019
       +servidor3   .GPS.     1   u    9   64  377  15.680   -0.005   0.026
       +servidor4   .IRIG.    1   u   30   64  377  15.582    0.004   0.100
       *servidor5   .GPS.     1   u   10   32  377   0.400   -0.026   0.049
       xservidor6   .IRIG.    1   u   26   64  377   7.824    9.923   0.367
        servidor7   .INIT.   16   u    - 1024    0   0.000    0.000 4000.00
       -servidor8   .ACTS.    1   u   13   64  377 202.274    2.459   0.309
        LOCAL(0)   LOCAL(0)  13   l   48   64  377   0.000    0.000   0.001


Voltar


 O Algorítmo de Agrupamento 
O algorítmo de Agrupamento trabalha com os servidores que são relógios 
verdadeiros, utilizando técnicas estatísticas, com o objetivo de 
selecionar os melhores dentre eles. Os critérios de seleção utilizados 
são: 

 estrato (stratum)

 distância para a raiz 

 variação (jitter)


No processo alguns servidores são descartados, sendo chamados de relógios afastados (outlyers). Os que permanecem são chamados de relógios sobreviventes (survivors), algumas vezes na literatura em inglês utiliza-se candidatos (candidates)
 no mesmo sentido que sobreviventes, por conta do algorítmo utilizado 
onde, à princípio, todos os relógios verdadeiros são candidatos, mas 
apenas alguns sobrevivem.


O melhor dos relógios sobreviventes é considerado como par do sistema (system peer).


Na consulta abaixo, o par do sistema é indicado pelo "*" (em verde); os relógios sobreviventes por "+" (em azul); e os relógios afastados por "-" (em laranja) (esses símbolos, como o "*", "+" e "-", usados para diferenciar os servidores, são chamados de tally-codes, para mais detalhes deve-se consultar a seção Utilizando.):



       usuario@cliente.local:~$ ntpq
       ntpq&gt; pe
         remote     refid    st   t when poll reach   delay   offset  jitter
       ======================================================================
       -servidor1   .IRIG.    1   u    8   32  377   0.407    0.248   0.016
       -servidor2   .GPS.     1   u    -   32  377   0.474    0.213   0.019
       +servidor3   .GPS.     1   u    9   64  377  15.680   -0.005   0.026
       +servidor4   .IRIG.    1   u   30   64  377  15.582    0.004   0.100
       *servidor5   .GPS.     1   u   10   32  377   0.400   -0.026   0.049
       xservidor6   .IRIG.    1   u   26   64  377   7.824    9.923   0.367
        servidor7   .INIT.   16   u    - 1024    0   0.000    0.000 4000.00
       -servidor8   .ACTS.    1   u   13   64  377 202.274    2.459   0.309
        LOCAL(0)   LOCAL(0)  13   l   48   64  377   0.000    0.000   0.001


Voltar


 O Algorítmo de Combinação de Relógios 
Se o algorítmo de Agrupamento encontrar apenas um sobrevivente, ele será o par do sistema e será utilizado como referência para ajustar o relógio local. Se for usada a palavra chave prefer na configuração de um servidor e este estiver dentre os sobreviventes,
 ele será considerado como par do sistema e, mesmo que existam outros 
sobreviventes, estes serão ignorados. Nesses casos, o algorítmo de 
Combinação de Relógios não é utilizado.


Para os demais casos, quando há mais do que um sobrevivente e nenhum deles foi configurado com a palavra chave prefer,
 o algorítmo de Combinação de Relógios calcula uma média ponderada dos 
deslocamentos dos relógios, com o objetivo de aumentar a exatidão.


No exemplo abaixo os 3 servidores destacados contribuem para o valor de 
deslocamento de -0,119ms, mostrado nas variáveis do sistema.



       usuario@cliente.local:~$ ntpq

       ntpq&gt; pe
         remote     refid        st   t when poll reach   delay   offset  jitter
       ==========================================================================
       +servidor1   .IRIG.        1   u    7   16  377    0.410   -0.087   0.022
       *servidor2   .GPS.         1   u    7   16  377    0.380   -0.128   0.052
       +servidor3   .IRIG.        1   u    5   16  377   14.750   -0.166   0.076
       -servidor4   200.1.2.123   2   u   15   16  377    0.449   -0.466   0.009
       xservidor5   .IRIG.        1   u   17   64  377    7.772    9.447   0.186
       xservidor6   .ACTS.        1   u   52   64  377  193.471    5.779   5.444
       -servidor    .GPS.         1   u    9   16  377    0.344   -0.486   0.071
       -servidor    200.1.2.123   2   u   45   64  377    4.437    1.423   0.723

       ntpq&gt; rl
       assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
       version="ntpd 4.2.2p4@1.1585-o Wed Mar  7 20:43:30 UTC 2007 (1)",
       processor="i686", system="Linux/2.6.20-16-generic", leap=00, stratum=2,
       precision=-20, rootdelay=0.380, rootdispersion=5.864, peer=40768,
       refid=servidor2,
       reftime=cad0765f.9bd22b77  Mon, Oct 29 2007 13:10:23.608, poll=4,
       clock=cad07677.9bbc05c3  Mon, Oct 29 2007 13:10:47.608, state=4,
       offset=-0.119, frequency=55.279, jitter=0.060, noise=0.014,
       stability=0.009, tai=0

No exemplo a seguir, apesar de haver 3 sobreviventes, foi usada a palavra chave prefer na configuração do servidor5.
 Como ele é um dos sobreviventes, foi escolhido como par do sistema e é o
 único responsável pelos parâmetros de sincronização. Nesse caso, o 
algorítmo de Combinação de Relógios não é utilizado:



       usuario@cliente.local:~$ ntpq

       ntpq&gt; pe

         remote     refid    st   t when poll reach   delay   offset  jitter
       ======================================================================
       -servidor1   .IRIG.    1   u    6   32  377    0.364    0.393   0.032
       -servidor2   .GPS.     1   u    1   32  377    0.415    0.357   0.012
       +servidor3   .GPS.     1   u   40   64  377   19.990    0.002   0.019
       +servidor4   .IRIG.    1   u   11   64  377   14.804    0.318   0.172
       *servidor5   .GPS.     1   u    5   32  377    0.366   -0.001   0.017
       xservidor6   .IRIG.    1   u   19   64  377    7.779    9.969   0.235

       ntpq&gt; rl
       assID=0 status=0654 leap_none, sync_ntp, 5 events, event_peer/strat_chg,
       version="ntpd 4.2.0a@1:4.2.0a+stable-8-r Mon Sep 18 19:09:33 UTC 2006 (1)",
       processor="i686", system="Linux/2.6.17-12-generic", leap=00, stratum=2,
       precision=-20, rootdelay=0.366, rootdispersion=12.913, peer=29992,
       refid=servidor5,
       reftime=cad07802.aea704bc  Mon, Oct 29 2007 13:17:22.682, poll=5,
       clock=cad0780b.f47980f5  Mon, Oct 29 2007 13:17:31.954, state=4,
       offset=-0.001, frequency=-23.914, noise=0.015, jitter=0.017,
       stability=0.037


Voltar


 Disciplina do Relógio Local 
O processo de disciplina do Relógio Local controla a fase e a freqüência
 do relógio do sistema. Ele é baseado na combinação de duas filosofias 
de controle bastante diferentes entre si: Phase Locked Loop (PLL) e Frequency Locked Loop (FLL)
 (traduções desses termos são incomuns, mas poderiam ser Laço Controlado
 por Fase e Laço Controlado por Freqüência). Ambas as filosofias 
implementam controles onde há realimentação, ou seja, onde a informação 
de saída é usada novamente na entrada, como simbolizado na Figura 2, no início desse texto.


O controle baseado em fase é melhor para as ocasiões onde há uma grande variação (jitter). Essa abordagem procura minimizar o erro no tempo, controlando indiretamente a freqüência.


O controle baseado em freqüência é melhor para quando há instabilidades na freqüência (variações mais lentas que o jitter, conhecidas como wander). A abordagem controla diretamente a freqüência, e indiretamente o erro no tempo.


O NTP disciplina o relógio local de forma contínua, mesmo em períodos 
onde não é possível consultar servidores de tempo. As características do
 relógio local são medidas e se tornam conhecidas do NTP, o que torna 
possível que ele funcione dessa forma. O arquivo indicado pela chave driftfile (geralmente /var/lib/ntp/ntp.drift) na configuração armazena o erro esperado de freqüência para o relógio.


Algumas características importantes desse algorítmo:

 

 Saltos no tempo são evitados sempre que possível. O tempo é 
ajustado para mais ou para menos gradualmente, variando-se a freqüência 
do relógio local.




 Se uma diferença maior do que 128ms for detectada o NTP considera 
que o tempo está muito errado, e que é necessário um salto para frente 
ou para trás para corrigi-lo. Contudo isso só é feito se essa diferença 
maior que 128ms persistir por um período maior que 900s (15min), para 
evitar que condições de congestionamento grave mas temporário na rede, 
que podem levar a medições erradas de tempo, causem inadvertidamente 
esse tipo de salto.




 Se uma diferença maior que 1000s (~16,7min) for detectada o 
algorítmo aborta a execução, considerando que algo muito errado 
aconteceu. Se houver diferenças dessa ordem ou maiores elas devem ser 
corrigidas manualmente antes de se executar o daemon NTP.



Voltar


 Segurança 
Por segurança no contexto da Tecnologia da Informação entende-se basicamente garantir quatro propriedades da informação: 

 integridade,

 disponibilidade,

 autenticidade e

 confidencialidade.


Os algorítmos vistos anteriormente, aliados à correta configuração do 
sistema, com um número suficiente de fontes de tempo com referências 
primárias independentes, garantem de forma satisfatória a integridade e disponibilidade do serviço de tempo.

Os algorítimos de criptografia abordados neste item visam garantir a autenticidade da informação. Ou seja, têm o objetivo de assegurar ao cliente de que o servidor é quem ele diz ser.


A confidencialidade não é considerada um problema no 
contexto do NTP. Ou seja, a informação de tempo sempre trafega na rede 
de forma aberta, sem criptografia, mesmo quando uma assinatura cifrada é
 utilizada para garantir a autenticidade da informação. As razões 
principais para o NTP funcionar dessa forma são que: 

 o tempo é uma informação pública, não há razão para esconder essa informação;

 trabalhar com a informação de tempo cifrada demandaria tempo 
tanto do servidor quando do cliente e degradaria o desempenho do 
sistema, fazendo-o menos exato.


Existem basicamente dois métodos no NTP para realizar a autenticação, chave simétrica (symmetric key) e  chave pública (autokey).


Autenticação por Chave Simétrica (Symmetric key)


A autenticação por chave simétrica é o esquema utilizado originalmente 
na versão 3 do NTP, mas mantido da versão 4. Um conjunto de chaves deve 
ser gerado e compartilhado entre servidor e cliente. O NTP não fornece 
meios para a transmissão ou armazenamento seguro das chaves; isso deve 
ser feito com outros recursos.


Chaves simétricas podem ser usadas para: 

 autenticar servidores ou pares no modo simétrico ativo;

 autenticar pares no modo simétrico passivo ou servidores broadcast ou multicast;

 autenticar requisições dos programas de monitoração e controle ntpq e ntpdc.


Quando o daemon NTP é iniciado, ele lê o arquivo de chaves especificado pelo comando keys no arquivo de configuração e armazena-as num cache. Cada chave deve ser ativada com o comando trustedkey antes de ser usada. Isso pode ser feito com o programa em funcionamento, utilizando o ntpdc. Os comandos requestkey e controlkey selecionam as chaves utilizadas para autenticar os programas ntpdc e ntpq. 


O arquivo de chaves pode conter várias chaves, uma em cada linha. Cada 
linha tem 3 colunas. A primeira é o número da chave, entre 1 e 65535. A 
segunda é o tipo da chave; recomenda-se utilizar M para MD5, que é 
representada por uma seqüência de até 31 caracteres ASCII (A versão 3 do
 NTP suportava também DES, mas além de ser pior, há problemas legais nos
 Estados Unidos, que consideram programas utilizando DES como munição, 
proibindo sua exportação). A terceira é a chave em si. 
Exemplo de arquivo com chaves:

       1   M    ABCDEFGHIJLMJNOPQRST
       2   M    ESSAEHUMACHAVEMD5VALIDA
       3   M    ESSAEHUMACHAVEMD5VALIDATB
       15  M    1234ACDAS@#$LKAS)KJDKASH
       498 M    NTPv4.98

Exemplo de utilização das chaves simétricas na configuração do ntp:

       server servidor1.dominio1 key 498
       server servidor2.dominio2 key 2
       peer   servidor3.dominio3 key 3

       # caminho para o arquivo com as chaves
       keys /etc/ntp.keys

       # define quais chaves são confiáveis
       trustedkey 2 15 498

       requestkey 15    # chave para utilizar o ntpq
       controlkey 15    # chave para utilizar o ntpqc

Autenticação por Chave Pública (Autokey)


Na versão 4 do NTP uma nova forma de autenticação é suportada, baseada em chaves públicas e num protocolo que foi chamado de autokey.
 A integridade dos pacotes é verificada através de chaves MD5 e a 
autenticidade das fontes de tempo é averiguada por meio de assinaturas 
digitais e vários esquemas de autenticação. Esquemas de identificação (identity schemes)
 baseados em trocas do tipo desafio/resposta são usados para evitar 
vários tipos de ataques aos quais o método de chaves simétricas é 
potencialmente vulnerável.


A autenticação é baseada em grupos de segurança (security groups). Pode-se entender um grupo de segurança
 como um conjunto de servidores e clientes NTP que compartilha os mesmos
 métodos de autenticação, tendo em sua raiz um ou mais servidores 
considerados confiáveis, e administrados por uma mesma entidade. Um 
grupo não necessariamente precisa ter servidores estrato 1 em sua raiz, 
mas pode ser cliente de outros grupos de segurança.


O número de opções que há para configurar-se o autokey é 
assustador. Contudo a configuração necessária para a maioria das 
situações é relativamente simples. Pode-se configurar um grupo de 
segurança com um ou mais servidores confiáveis (TH - Trusted Hosts) no estrato mais baixo. Elege-se um desses servidores para ser o agente confiável (TA - trusted agent)
 e gerar os certificados privados, um certificado público auto assinado,
 e chaves de identificação privadas. Se houver mais de um servidor 
confiável, esses certificados e chaves são copiados para os demais 
manualmente.


Os demais clientes e servidores geram chaves privadas e certificados 
auto assinados considerados não confiáveis. Cada um deles fornece sua 
senha ao agente confiável e requisita  as chaves e certificados do grupo
 (isso pode ser feito por email ou por um formulário web, por exemplo). 
Para os servidores são fornecidas chaves cifradas. Para os clientes 
somente um subconjunto de parâmetros de identificação não criptografados
 é fornecido.


O autokey se encarrega de resgatar os certificados ao longo da 
cadeia de servidores NTP até chegar a um servidor confiável, garantindo 
que toda a cadeia de servidores é confiável.


Para garantir a integridade dos pacotes assinaturas baseadas no endereço
 IP são utilizadas. O endereço tem de ser o mesmo, então, para o cliente
 e para o servidor, o que significa que a autenticação baseada em chave 
pública não funciona em conjunto com NAT.


Mais detalhes de configuração do autokey podem ser obtidos na documentação oficial do NTP.