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

[Carlos M. Martinez]

DANE creo que es una de las cosas mas prometedoras que estan en
discusion en este momento. Cualquier cosa que podamos hacer para
apoyarlo, arriba :D

s2

~Carlos

On 8/9/13 10:48 AM, Arturo Servin wrote:
> 
> 	No se mucho del tema y no me ofrezco a participar pero yo me hago
> hincha de ustedes en la lista del WG si lo envian. La idea parece muy
> interesante.
> 
> Slds
> as
> 
> On 8/8/13 5:19 PM, Antonio M. Moreiras wrote:
>> Eu não conhecia esse WG (DANE). Muito boa sugestão. Vou estudar os
>> documentos do grupo.
>>
>> []s
>> Moreiras.
>>
>> On 08/08/13 11:51, Hugo Salgado 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
>