[Ietf-lac] parâmetros IFF do Autokey do NTP distribuidos via DNSSEC

[Roque Gagliano (rogaglia)]

Antonio,

Otra alternativa es que simplemente baje el hash de la clave por DNSSEC pero obtenga la clave en-línea por otro mecanismo. Así funciona DNSSEC+SSH y creo que es más light que DANE que está pensado para bajar todo un certificado.

El RR sería el SSHFP.

Algunos ejemplos:
http://tools.ietf.org/html/rfc4255
https://spaces.internet2.edu/display/~benchoff@vt.edu/DNSSEC+and+SSH+Key+Fingerprints

slds
r.


On Aug 8, 2013, at 4:51 PM, Hugo Salgado <hsalgado at nic.cl> wrote:

> Hola Antonio.
> Me parece una excelente idea. Pero recomendaría ponerlo dentro del
> trabajo de DANE. No conozco mucho de NTP ni Autokey, pero si se trata
> de la publicación de una llave formateada al estilo X.690, y el
> protocolo es TLS, entonces es justo lo que DANE permite hacer. En
> ese caso, bastaría con un registro en el DNS del estilo
> 
>  _563._tcp.ntp.example.com IN TLSA ( .... )
> 
> De todas formas sería necesario un documento explicando los detalles
> específicos de Autokey, al estilo de lo que se está haciendo con SMTP:
> 
>  https://tools.ietf.org/wg/dane/draft-ietf-dane-smtp/
> 
> Cuenta conmigo si necesitas ayuda de texto o revisión.
> 
> Saludos,
> 
> Hugo
> 
> 
> On 08/07/2013 09:00 PM, Antonio M. Moreiras wrote:
>> Eu não tenho certeza sobre a utilidade, ou viabilidade, dessa proposta.
>> Mas pensei em fazer isso há algum tempo, e gostaria que vocês comentassem.
>> 
>> Alguns servidores NTP disponibilizam Autokey (RFC 5906). Resumidamente,
>> é uma tecnologia de segurança que pode ser usada opcionalmente pelos
>> clientes para garantir a autenticidade e integridade da informação
>> recebida dos servidores.
>> 
>> Pessoalmente, acredito que configurar diversas fontes NTP é o suficiente
>> para garantir o funcionamento correto de um cliente, e inviabilizar um
>> possível ataque. Também acho que não há muita motivação para alguém
>> atacar a estrutura NTP, havendo outros alvos mais fáceis e
>> interessantes. No entanto, nem todos pensam assim, e há quem ache o
>> Autokey algo útil e desejável. Então, diversos servidores públicos
>> oferecem essa possibilidade, inclusive os servidores que o NIC.br
>> administra, no Brasil.
>> 
>> Um dos passos para que o cliente configure a funcionalidade é que ele
>> recupere, com garantia de autenticidade e integridade, um arquivo
>> público contendo uma chave DSA no formato PEM. Uma forma de se fazer
>> isso é colocar essa informação num sítio https.
>> 
>> Ao invés de usar um sítio https, me parece que se poderia colocá-la no
>> DNS dos respectivos servidores e recuperá-la com garantia de
>> autenticidade e integridade usando o DNSSEC. Isso facilitaria,
>> potencialmente, a configuração automática do Autokey, desde que o
>> software cliente seja alterado. Talvez se possa usar o campo TXT no
>> formato especificado na RFC 1464 para armazenar a informação. Talvez
>> algum outro campo.
>> 
>> Embora eu não seja um forte defensor do Autokey, em si, acredito que
>> facilitar a configuração do NTP, em qualquer aspecto, pode ser benéfico,
>> de forma geral, e facilitar sua adoção.
>> 
>> Existem mais possibilidades de configuração do Autokey do que técnicas
>> de transição no IPv6 (para quem não entendeu a piada, são muitas, uma
>> quantidade exagerada e assustadora). Há muitas possibilidades de
>> definição de grupos seguros e esquemas de identificação. Não tenho muita
>> certeza se alguém além do David Mills entende todas essas diferentes
>> possibilidades. Eu certamente não as conheço totalmente. A proposta não
>> abrangeria todos os métodos. Apenas um subset, que escolhemos por
>> considerarmos operacionalmente mais prático para uso na Internet.
>> 
>> Alguém por aqui acha que isso seria útil?
>> 
>> []s
>> Moreiras.
>> _____________________________________________
>> Ietf-lac mailing list
>> Ietf-lac at lacnog.org
>> Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org
>> 
> _____________________________________________
> Ietf-lac mailing list
> Ietf-lac at lacnog.org
> Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4459 bytes
Desc: not available
URL: <https://mail.lacnic.net/pipermail/ietf-lac/attachments/20130820/9daa8ecd/attachment.bin>