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

[Hugo Salgado]

Que tal Roque.
DANE permite incluir solo un hash, con el campo "selector" en 1 o 2:


; <<>> DiG 9.8.4-P2 <<>> _443._tcp.www.vulcano.cl tlsa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58145
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_443._tcp.www.vulcano.cl.	IN	TLSA

;; ANSWER SECTION:
_443._tcp.www.vulcano.cl. 60	IN	TLSA	3 0 1 5F301AD10923161E74EC4951C052C97963FEBCCB093019618964D69C AF7B5B34

;; Query time: 587 msec
;; SERVER: 71.252.219.43#53(71.252.219.43)
;; WHEN: Tue Aug 20 07:56:29 2013
;; MSG SIZE  rcvd: 89


Saludos,

Hugo


"Roque Gagliano (rogaglia)" <rogaglia at cisco.com> wrote:
>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
>> 

--
Escrito en un teclado virtual. Disculpe abreviaciones y errores.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/ietf-lac/attachments/20130820/d7e57217/attachment.html>