forum.opennet.ru

Форум Маршрутизаторы CISCO и др. оборудование. (Безопасность)
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац, Velos (ok), 16-Авг-10, (0) [смотреть все]

gt оверквотинг удален 1 исключительно для аутентификации peer-ов2 Все сове, Pve1 (ok), 08:44 , 17-Авг-10, (1) //

1я сам юниксоид, но пользуем IAS, так как не нужно интегрировать руками , Gbyte (ok), 08:50 , 17-Авг-10, (2) //

gt оверквотинг удален Ну тут так сложилось исторически, в боевой схеме сейч, Velos (ok), 22:02 , 17-Авг-10, (3) //

В итоге сделал на IAS Работает Правда в отличие от freeRADIUS-а, access-лис, Velos (ok), 23:48 , 30-Авг-10, (5)

Добрый день Подскажите, скорее всего вы уже разобрались Поднимаю vpn на ASA 55, svetts (??), 20:10 , 23-Июн-11, (6)

На ASA сертификаты могут использоваться только на первой фазе IKE - аутентификац, Velos (ok), 23:28 , 23-Июн-11, (7)

Сообщения [Сортировка по времени | RSS]

3. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац" +/–

Сообщение от Velos (ok), 17-Авг-10, 22:02

>[оверквотинг удален]
>>и ntlm не оч секьюрно.   Есть же виндовый IAS,
>>который уже интегрирован с AD?
>>По крайней мере на 2008R2 в NAP это делается легко. А там,
>>как я понял - тот же IAS, немного в другой оболочке.
>>И инфраструктура однообразной будет.
>
>+1
>
>я сам юниксоид, но пользуем IAS, так как не нужно интегрировать руками.
>
Ну... тут так сложилось исторически, в боевой схеме сейчас работает RADIUS, поэтому предложенное решение должно выписываться в существующую схему. Переход на IAS планируется...
Ещё вот такой вопросик по пункту 1: получается для проверки ЭЦП, peer-ы дожны что-то некий набор бит друг другу послать, чтоб затем каждая из сторон это значение зашифровав закрытым ключём, вернула обратно, а отправляющая смогла это расшифровать и сравнить с оригиналом. Это ведь так? А вот что они посылают друг другу? Или используется другая схема? Я просто не могу понять, как обладатель сертификата подтверждает владение закрытым ключем.

Ответить | Правка | Наверх | Cообщить модератору

5. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац" +/–

Сообщение от Velos (ok), 30-Авг-10, 23:48

В итоге сделал на IAS :) Работает ) Правда в отличие от freeRADIUS-а, access-лист завязать получается только на AD-ой группе, а не на пользователя.
>Ещё вот такой вопросик по пункту 1: получается для проверки ЭЦП, peer-ы
>дожны что-то некий набор бит друг другу послать, чтоб затем каждая
>из сторон это значение зашифровав закрытым ключём, вернула обратно, а отправляющая
>смогла это расшифровать и сравнить с оригиналом. Это ведь так? А
>вот что они посылают друг другу? Или используется другая схема? Я
>просто не могу понять, как обладатель сертификата подтверждает владение закрытым ключем.
>
Судя по данной инфе http://www.ciscopress.com/articles/article.asp?p=24833&seqNum=5
насколько я понял происходит всё следующим образом:
1.    Клиент соединяется с ASA, peer-ы производят обмен сертификатами, которые будут использоваться для аутентификации каждой из сторон в Phase 1 IKE.
2.    ASA и клиент загружают CRL, после чего каждая из сторон проверяет подлинность сертификата противоположного peer-a.
3.    Если сертификат каждой стороны действительный (не истек срок действия и его нет в CRL), начинается IKE Phase 1. Стороны согласуют параметры безопасности (SA): алгоритм шифрования, алгоритм хеширования и группу Диффи-Хельмана. Также происходит обмен peer ID,  которые с помощью закрытого ключа каждой из сторон подписываются. (В качестве ID выступают либо FQDN или IP-адрес каждой из сторон - или что-то ещё...). Если подпись верна – этот параметр учувствует в выработке общего сессионного ключа DH.
Так ли это? :)
Такой вопрос по-поводу xauth:
после того, как тунель будет установлен, от пользователя потребуется ввести логин и пароль. (Для тунельной группы назначен authentication-server-group).
А возможно ли избавится от этой части, взяв в качестве логина значение из сертификата?
Насколько я понял, сделать это нужно как-то так:

asa#(config)tunnel-group VPN general-attributes
asa(config-tunnel-general)# authorization-dn-attributes CN (к примеру)

Правильно ли это? Или же назначение на тунельной группе authentication-server-group однозначно предполагает аутентификацию?
Насколько я понял, фичи "pre-fill username" и "username-from-certificate", доступные в IOS 8.2(1)  всего лишь заполняют имя пользователя заранее... Но как таковую, аутнетификацию пользователя не отменяют.

Ответить | Правка | Наверх | Cообщить модератору

6. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац" +/–

Сообщение от svetts (??), 23-Июн-11, 20:10

Добрый день!
Подскажите, скорее всего вы уже разобрались=)
Поднимаю vpn на ASA 5520 + CA.
AD не учавствует на данном этапе.
Получается,что любой юзер может скачать сертификат c CA и подрубиться, пройдя local аутентификацию к ASA5520-ведь сертификаты у них одинаковые..
Существует ли возможность контролировать подключение VPNclienta с помощью центра сертификации?

Ответить | Правка | Наверх | Cообщить модератору

7. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац" +/–

Сообщение от Velos (ok), 23-Июн-11, 23:28

> Добрый день!
> Подскажите, скорее всего вы уже разобрались=)
> Поднимаю vpn на ASA 5520 + CA.
> AD не учавствует на данном этапе.
> Получается,что любой юзер может скачать сертификат c CA и подрубиться, пройдя local
> аутентификацию к ASA5520-ведь сертификаты у них одинаковые..
> Существует ли возможность контролировать подключение VPNclienta с помощью центра сертификации?
На ASA сертификаты могут использоваться только на первой фазе IKE - аутентификации peer-ов (фактически - рабочих станций, с которых строится туннель). После первой фазы - идёт аутентификация пользователя (xauth) - в Ipsec реализации циски она возможна только через ввод логина/пароля (EAP у меня по-крайней мере так и не получилось прикурить к этой конструкции). Поэтому как производится xauth - локально, через внешний сервер или вообще не производится - с т.з. использования сертификата в Phase 1 - нет никакой разницы.
Т.е.сертификаты по-сути в Isec позволяют уйти от необходимости передачи разделенного секрета.
Также появляеся возможность управлением подключениями с помощью выданных сертификатов. Отзывая сертификат - вы фактически запретите обладателю закрытого ключа подключаться.
Если Вы переживаете за то, что пользователь скачает сертификат УЦ и предоставит его - спешу успокоить - всё в порядке :)
Очень советую почитать про основы ассиметричной крпитографии вот тут:
https://rapidshare.com/files/2637983018/____________________...
Этот документ я немного подправил в своё время - в оригинале было пара опечаток на картинках. Но сам документ напсан очень простым языком и очень доступно.

Суть в том, что сам по себе сертификат не имеет никакой ценности - он наоборот создан для того, чтобы его можно было свободно и без опасений распространять всем желающим. Главное - это закрытый ключ, который соотвествует сертификату.
Т.е. когда peer устанавливает подключение с ASA с использовании сертификата - просиходит обмен параметрами DH. Точно такой же обмен производится и без использования сертификатов, разница только в том, что параметры подписываются закрытыми ключами каждой из сторон. При этом подпись будет считаться верной, в случае если ни один из сертификатов каждой стороны не отозван и выданы они удостоверяющим центром, которому доверяют оба.
Скачав сертификат УЦ - я не скачаю его закрытый ключ :) А значит не смогу подписать параметры, необходимые для генерации сессионого ключа через алгоритм DH.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	3. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац"	+/–
	Сообщение от Velos (ok), 17-Авг-10, 22:02
	>[оверквотинг удален] >>и ntlm не оч секьюрно. Есть же виндовый IAS, >>который уже интегрирован с AD? >>По крайней мере на 2008R2 в NAP это делается легко. А там, >>как я понял - тот же IAS, немного в другой оболочке. >>И инфраструктура однообразной будет. > >+1 > >я сам юниксоид, но пользуем IAS, так как не нужно интегрировать руками. > Ну... тут так сложилось исторически, в боевой схеме сейчас работает RADIUS, поэтому предложенное решение должно выписываться в существующую схему. Переход на IAS планируется... Ещё вот такой вопросик по пункту 1: получается для проверки ЭЦП, peer-ы дожны что-то некий набор бит друг другу послать, чтоб затем каждая из сторон это значение зашифровав закрытым ключём, вернула обратно, а отправляющая смогла это расшифровать и сравнить с оригиналом. Это ведь так? А вот что они посылают друг другу? Или используется другая схема? Я просто не могу понять, как обладатель сертификата подтверждает владение закрытым ключем.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац"	+/–
	Сообщение от Velos (ok), 30-Авг-10, 23:48
	В итоге сделал на IAS :) Работает ) Правда в отличие от freeRADIUS-а, access-лист завязать получается только на AD-ой группе, а не на пользователя. >Ещё вот такой вопросик по пункту 1: получается для проверки ЭЦП, peer-ы >дожны что-то некий набор бит друг другу послать, чтоб затем каждая >из сторон это значение зашифровав закрытым ключём, вернула обратно, а отправляющая >смогла это расшифровать и сравнить с оригиналом. Это ведь так? А >вот что они посылают друг другу? Или используется другая схема? Я >просто не могу понять, как обладатель сертификата подтверждает владение закрытым ключем. > Судя по данной инфе http://www.ciscopress.com/articles/article.asp?p=24833&seqNum=5 насколько я понял происходит всё следующим образом: 1. Клиент соединяется с ASA, peer-ы производят обмен сертификатами, которые будут использоваться для аутентификации каждой из сторон в Phase 1 IKE. 2. ASA и клиент загружают CRL, после чего каждая из сторон проверяет подлинность сертификата противоположного peer-a. 3. Если сертификат каждой стороны действительный (не истек срок действия и его нет в CRL), начинается IKE Phase 1. Стороны согласуют параметры безопасности (SA): алгоритм шифрования, алгоритм хеширования и группу Диффи-Хельмана. Также происходит обмен peer ID, которые с помощью закрытого ключа каждой из сторон подписываются. (В качестве ID выступают либо FQDN или IP-адрес каждой из сторон - или что-то ещё...). Если подпись верна – этот параметр учувствует в выработке общего сессионного ключа DH. Так ли это? :) Такой вопрос по-поводу xauth: после того, как тунель будет установлен, от пользователя потребуется ввести логин и пароль. (Для тунельной группы назначен authentication-server-group). А возможно ли избавится от этой части, взяв в качестве логина значение из сертификата? Насколько я понял, сделать это нужно как-то так: asa#(config)tunnel-group VPN general-attributes asa(config-tunnel-general)# authorization-dn-attributes CN (к примеру) Правильно ли это? Или же назначение на тунельной группе authentication-server-group однозначно предполагает аутентификацию? Насколько я понял, фичи "pre-fill username" и "username-from-certificate", доступные в IOS 8.2(1) всего лишь заполняют имя пользователя заранее... Но как таковую, аутнетификацию пользователя не отменяют.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац"	+/–
	Сообщение от svetts (??), 23-Июн-11, 20:10
	Добрый день! Подскажите, скорее всего вы уже разобрались=) Поднимаю vpn на ASA 5520 + CA. AD не учавствует на данном этапе. Получается,что любой юзер может скачать сертификат c CA и подрубиться, пройдя local аутентификацию к ASA5520-ведь сертификаты у них одинаковые.. Существует ли возможность контролировать подключение VPNclienta с помощью центра сертификации?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац"	+/–
	Сообщение от Velos (ok), 23-Июн-11, 23:28
	> Добрый день! > Подскажите, скорее всего вы уже разобрались=) > Поднимаю vpn на ASA 5520 + CA. > AD не учавствует на данном этапе. > Получается,что любой юзер может скачать сертификат c CA и подрубиться, пройдя local > аутентификацию к ASA5520-ведь сертификаты у них одинаковые.. > Существует ли возможность контролировать подключение VPNclienta с помощью центра сертификации? На ASA сертификаты могут использоваться только на первой фазе IKE - аутентификации peer-ов (фактически - рабочих станций, с которых строится туннель). После первой фазы - идёт аутентификация пользователя (xauth) - в Ipsec реализации циски она возможна только через ввод логина/пароля (EAP у меня по-крайней мере так и не получилось прикурить к этой конструкции). Поэтому как производится xauth - локально, через внешний сервер или вообще не производится - с т.з. использования сертификата в Phase 1 - нет никакой разницы. Т.е.сертификаты по-сути в Isec позволяют уйти от необходимости передачи разделенного секрета. Также появляеся возможность управлением подключениями с помощью выданных сертификатов. Отзывая сертификат - вы фактически запретите обладателю закрытого ключа подключаться. Если Вы переживаете за то, что пользователь скачает сертификат УЦ и предоставит его - спешу успокоить - всё в порядке :) Очень советую почитать про основы ассиметричной крпитографии вот тут: https://rapidshare.com/files/2637983018/____________________... Этот документ я немного подправил в своё время - в оригинале было пара опечаток на картинках. Но сам документ напсан очень простым языком и очень доступно. Суть в том, что сам по себе сертификат не имеет никакой ценности - он наоборот создан для того, чтобы его можно было свободно и без опасений распространять всем желающим. Главное - это закрытый ключ, который соотвествует сертификату. Т.е. когда peer устанавливает подключение с ASA с использовании сертификата - просиходит обмен параметрами DH. Точно такой же обмен производится и без использования сертификатов, разница только в том, что параметры подписываются закрытыми ключами каждой из сторон. При этом подпись будет считаться верной, в случае если ни один из сертификатов каждой стороны не отозван и выданы они удостоверяющим центром, которому доверяют оба. Скачав сертификат УЦ - я не скачаю его закрытый ключ :) А значит не смогу подписать параметры, необходимые для генерации сессионого ключа через алгоритм DH.
	Ответить \| Правка \| Наверх \| Cообщить модератору