Протокол о создании: Образец решения единственного учредителя о создании ООО 2021

Содержание

Протокол общего собрания учредителей

Если в регистрируемом Обществе с ограниченной ответственностью, больше одного учредителя, то до регистрации в налоговой нужно провести общее собрание учредителей и составить протокол по его итогам.

Структура протокола общего собрания учредителей должна содержать следующие элементы: шапку, непосредственный текст решения, подвал (заверка решения).

Заголовок протокола собрания учредителей

Чтобы документ имел полную юридическую силу, заголовок должен начинаться со слов «Протокол N 1 общего собрания учредителей «Общество с ограниченной ответственностью» и далее должно следовать полное наименование компании.

Дата документа проставляется исходя из времени проведения собрания, а не в тот момент, когда был оформлен сам протокол. Её обычно располагают на следующей строке после слова «ПРОТОКОЛ» или перед специальной линией-ограничителем.

После даты и номера необходимо указать место, где произошло собрание. При указании населённого пункта можно использовать сокращения: город — г., область — обл. и так далее.

Пропишите ниже полный адрес места проведения собрания, а также более детально время его проведения: во сколько началось и закончилось собрание. Также укажите лицо, которое вело подсчет голосов.

Вводная часть содержания протокола

Основной текст протокола состоит из двух частей. Первая — вводная, заполняется строго по образцу. Вторая — основная оформляется в свободной форме.

Во вводной части текста необходимо указать данные о составе учредителей, которые принимали участие в собрании, а также повестку дня.

Указание учредителей допускается в виде простого текста или в виде таблицы с данными.

Обязательно нужно указать следующие данные учредителей: фамилии, имена, отчества, данные паспорта и адреса регистрации.

Если речь идёт о юридическом лице, то указываются: название организации, ИНН, ОГРН, а также данные представителя компании.

Повестка дня

Повестка дня также прописывается в документе, а после этих слов идёт нумерованное перечисление вопросов, которые были рассмотрены на собрании.

В протоколе собрания учредителей ООО, главными пунктами являются:

  • Избрание председательствующего и секретаря собрания. Они выбираются из состава учредителей.
  • Об учреждении общества, при этом нужно утвердить его фирменное наименование и местонахождение общества.
  • Об утверждении устава общества.
  • О размере, способе, порядке и сроках оплаты уставного капитала.
  • Определить размер и номинальную стоимость доли каждого из учредителей.
  • Об избрании органов управления общества (в основном – избрание только Генерального директора).
  • Если в уставе ООО будет указан контрольный орган, необходимо сразу сформировать ревизионную комиссию (ревизора) Общества.
  • Если в уставе будет указан обязательный ежегодный аудит общества, или он предусмотрен законодательством, то сразу нужно утвердить аудитора общества.
  • Определить, кто из учредителей будет оплачивать государственную пошлину за государственную регистрацию общества и осуществлять все иные действия необходимые для регистрации общества.

Принятие решений по вопросам повестки дня

После указания всех вопросов повестки дня идет фиксирования непосредственно принятых решений.

Каждый вопрос из повестки дня, расписывается: какой вопрос рассматривали, какое решение приняли, количество голосов.

При этом обязательно указывается количество голосов, отданных участниками за принятие решения по каждому вопросу, количество голосов, отданных против, а также количество голосов участников, воздержавшихся от голосования.

Заключительная часть

Исходя из требований законодательства, в протоколе достаточно подписей председательствующего и секретаря, но лучше, если ниже протокол подпишут все учредители общества.

Если протокол больше, чем на одном листе, его необходимо прошить, пронумеровать страницы и на обороте заверить подписями председательствующего и секретаря.

Рекомендуем сделать несколько экземпляров протокола о создании, так как в будущем при смене состава участников, в случае потери протокола, восстановить этот документ очень сложно.

Протокол о создании ООО — шаг 6

Правила написания протокола

Действующий Федеральный закон «Об обществах с ограниченной ответственностью» предусматривает, что компания создается на основании решения её учредителей или учредителя (ст. 11 ФЗ «Об ООО» от 08.02.1998 N 14-ФЗ (ред. от 29.12.2012, с изм. от 23.07.2013). Если у организации несколько предполагаемых участников, решение об учреждении ООО принимается в виде протокола.

По своей правовой природе данный акт представляет собой акт выражения воли физических и (или) юридических лиц на появление новой организации, нового субъекта права.

Воля должна быть сформирована и выражена надлежащим образом, что достигается за счет соблюдения требований к оформлению и содержанию письменного волеизъявления.

Протокол учредителей о создании ООО должен содержать ряд вопросов повестки дня, которые необходимо разрешить в его тексте в соответствии с упомянутым выше законом:

  1. О создании общества с ограниченной ответственностью.
  2. О выборе председателя и секретаря собрания учредителей.
  3. Об установлении места нахождения.
  4. Об определении размера уставного капитала.
  5. Об определении размера и номинальной стоимости доли учредителя, а также порядка, формы и срока оплаты уставного капитала создаваемой организации.
  6. Об утверждении устава.
  7. Об избрании исполнительного органа.
  8. О государственной регистрации учреждаемой организации (данный вопрос не относится подлежащих обязательному разрешению, но на практике часто включается в текст).

По каждому из приведенных вопросов происходит голосование. Решения по вопросам № 1, 5, 6 принимаются учредителями общества единогласно. После того, как по всем пунктам достигнута определенность, протокол о создании ООО подписывают сначала председатель, а потом секретарь общего собрания.

Решение о создании общества с одним участником

В случае если у общества с ограниченной ответственностью не несколько учредителей, а один, он принимает решение об учреждении ООО единолично. Оно должно определять размер уставного капитала общества, срок и тот порядок, в котором уставный капитал будет оплачен, а также размер и номинальную стоимость доли, которая принадлежит каждому из учредителей, помимо вопросов, указанных применительно к протоколу (за исключением вопроса о выборе председателя и секретаря собрания).

Структура документа такова:

  • Название: Решение № 1 единственного учредителя.
  • Фамилия, имя, отчество и подпись.
  • Место и дата принятия решения.
  • Паспортные данные лица, принимающего решение.
  • Собственно текст документа, в котором отражены ответы на перечисленные выше вопросы.
  • Подпись учредителя.

Рассматриваемый документ, так же как и протокол общего собрания, должен наличествовать в двух экземплярах, поскольку один экземпляр передается в налоговый орган в комплекте документов для государственной регистрации юридического лица при создании, а другой остается в организации.

На практике можно наблюдать довольно распространенную ошибку: после государственной регистрации, когда материалы получены из налогового органа, компания получает печать, и оттиск ставится на решении о создании (например, такую ошибку может сделать сотрудник консалтинговой компании, который первый раз ассистирует в регистрации ООО или кто-либо из сотрудников организации по принципу «от печати хуже не станет»). Это пример неправильного оформления решения или протокола о создании ООО сразу по нескольким причинам:

  • Экземпляр, оставшийся в фирме, должен быть идентичен тому, который подан в налоговый орган.
  • До внесения записи о создании компании в Единый государственный реестр юридических лиц (ЕГРЮЛ) она не считается образованной, следовательно, печати такой организации не может существовать.

Заверение протокола

Действующее отечественное законодательство, регулирующее порядок образования обществ с ограниченной ответственностью не требует нотариального заверения протокола (решения) о создании фирмы.

Нотариального удостоверения не требует также доверенность, выдаваемая лицу, уполномоченному подать комплект документов в налоговый орган для государственной регистрации и получить соответствующие документы, когда запись о создании ООО внесена в ЕГРЮЛ. Если учредителей несколько, достаточно простой письменной доверенности от каждого из них. Это связано с утверждением новых форм заявлений, подаваемых в налоговый орган.

Многие нотариусы хотят ознакомиться с протоколом о создании компании перед заверением указанных документов, чтобы удостовериться, что воля на образование юридического лица выражена надлежащим образом, а в заявление внесены сведения о надлежащих субъектах (учредителях).

Следует отметить, что протокол (решение) о создании не относится к числу учредительных документов организации, однако к его составлению необходимо отнестись крайне внимательно, так как в ходе осуществления компанией деятельности контрагенты, банки, государственные органы могут изъявить желание ознакомиться с ним, чтобы удостовериться, что организация создана в соответствии с законодательством, а также для подтверждения личности учредителя (например, при принятии им решения об отчуждении принадлежащей ему доли в уставном капитале юридического лица).

Также следует указать, что согласно статье 50 ФЗ «Об обществах с ограниченной ответственностью», предприятие обязано хранить данный документ по месту нахождения его единоличного исполнительного органа либо в другом месте, которое известно участникам общества и у них есть возможность доступа к документу.

←Предыдущий шаг                  Следующий шаг→

Протокол о создании ооо образец бланк (бланк, образец

Организации создаются по единогласному добровольному решению совладельцев. Естественно будет предположить, что данное решение должно быть задокументировано.

Таким документом, подтверждающим согласие соучредителей создать совместное предприятие, является протокол.

Для его составления необходимо провести собрание будущих совладельцев. Они, в свою очередь, приступают к переговорам.

Выводами из них будут служить размеры долевых участий, объем уставного фонда и так далее. Но в первую очередь, в этом протоколе должно быть отображено само решение о создании предприятия.

 

Законодательное обоснование написания документа

Как говорилось ранее, необходимым требованием для оформления протокола является созыв общего учредительного собрания. Об этом говориться в соответствующем законе об «ООО». Законодательство не обуславливает порядок и принципы проведения такого рода собраний. Поэтому к нему применяются общепринятые требования. Они прописаны в четвертой главе все того же закона.

В документе (протоколе) должен быть описан весь процесс учредительного собрания, равно как и перечислены все принятые решения. Составление данного документа не является моментом создания предприятия. Компания начинает свою деятельность только с момента ее государственной регистрации. Здесь следует отметить лишь то, что без протокола предприятие зарегистрировано не будет. Наличие данного документа является обязательным.

 

Структура и содержание документа о создании «ООО»

В соответствии все с тем же законом, на общем собрании учредителей должны быть приняты решения по ключевым моментам создания компании. В первую очередь, это решение о регистрации «ООО». Второе – необходимо указать то, что все участники согласны с предоставленным уставом предприятия.

В общепринятых нормах проведения собраний оговорена необходимость наличия председателя. Об этом должна быть внесена соответствующая отметка. Там же приводятся данные о секретаре. Именно секретарь будет оформлять этот документ.

Участникам обсуждений необходимо будет избрать ряд руководящих органов. Во-первых, должен быть избран единоличный исполнитель. Во-вторых, избираются коллегиальные исполнители.

Кроме этого, определяется состав совета директоров, ревизионной комиссии и единоличного ревизора. Возможно проведение избрания аудитора и других органов.

Данный документ подписывает председатель, секретарь, а также все совладельцы компании. Все решения должны быть приняты единогласно. Об этом должна быть свидетельствовать соответствующая запись.

Храниться этот документ должен у единовластного руководителя (гендиректора). Каждый из совладельцев имеет право беспрепятственно получить доступ к нему по первому же требованию. Ниже приведены ссылки на бесплатные образцы таких протоколов.

Ниже расположен типовой пример и форма протокола о создании ооо вариант которого можно скачать бесплатно.

Протокол собрания учредителей о создании ООО

Протокол общего собрания учредителей ООО необходим для того, чтобы зафиксировать решение нескольких лиц о намерении создать фирму. Помимо того, что протокол облачает волю учредителей на регистрацию ООО в письменную форму, в нем отражаются и иные важные для работы будущей организации вопросы: об утверждении устава, о выборе директора, и т.д. В публикации подробно рассмотрена процедура составления протокола собрания учредителей фирмы.

СОДЕРЖАНИЕ СТАТЬИ:

Общее собрание учредителей ООО: порядок проведения с целью утверждения протокола о создании фирмы

Перед освещением вопроса необходимо разобраться с терминологией. Законом разграничены понятия: участник и учредитель фирмы. Учредителями называются лица, которые учреждают организацию, которая будет зарегистрирована в будущем. Статус участников бывшие учредители получают после регистрации ООО.

Протокол общего собрания учредителей входит в перечень документов, обязательных для регистрации фирмы несколькими лицами. Порядок составления протокола регламентирован ст. 181.2 ГК РФ, ст. 11, 15 ФЗ «Об обществах с ограниченной ответственностью» от 08.02.1998 № 14-ФЗ. В то же время законом не предусмотрен порядок проведения общего собрания учредителей до регистрации ООО. На практике, процедура, предусмотренная для участников ООО, применяется и учредителями фирмы, которые проводят общее собрание с целью принятия решения об учреждении организации.

Перед собранием подготавливается повестка дня, в которую вносятся различные вопросы, имеющие значение при создании фирмы и требующие разрешения путем голосования учредителей.

В частности, учредители должны проголосовать по вопросам:

  • учреждения фирмы;
  • принятия ее устава;
  • назначения директора;
  • другим важным вопросам.

Повестка заранее направляется учредителям фирмы для ознакомления ответственным лицом. Целесообразно также направить учредителям уведомление о времени и месте проведения собрания.

Перед обсуждением вопросов из числа учредителей избираются председатель собрания и секретарь. Председатель выполняет роль арбитра, ведет собрание, а секретарь фиксирует его ход. Вопросы повестки дня поэтапно обсуждаются на собрании, и разрешаются путем голосования учредителей. О том, как процесс протоколируется, какие сведения заносятся в протокол, поговорим подробнее далее.

Для учреждения фирмы несколькими учредителями, «за» должны проголосовать все 100 % из них (п. 3 ст. 11 ФЗ № 14). Аналогичное правило действует в отношении вопроса об утверждении устава.

Порядок составления протокола собрания учредителей о создании ООО

Протокол составляется в письменном виде (п. 3 ст. 181.2 ГК РФ). Закон не содержит положений относительно того, в течение какого времени после проведения собрания протокол должен быть составлен, соответственно этот вопрос разрешается участниками, или остается на усмотрение секретаря собрания, который может быть избран из их числа.

Нет правовой регламентации того, каким образом должен выглядеть протокол. Не утверждена и его форма. Соответственно, можно составлять документ в произвольном виде, однако не следует забывать о требованиях к содержанию протокола, предусмотренных ст. 181.2 ГК РФ.

В протоколе должны найти отражение:

  1. Дата и время проведения собрания.
  2. Информация об участниках обсуждения (достаточно указания Ф.И.О.).
  3. Результаты голосования (по каждому вопросу повестки дня отдельно).
  4. Информацию о лицах, которые занимались подсчетом голосов.
  5. Информацию о лицах, голосовавших «против» принятия решения собрания.

Протокол должен подписать как председатель, так и секретарь собрания.

В силу п. 3 ст. 67.1 ГК РФ протокол требует нотариального заверения, либо должен составляться при ведении видео- или аудиозаписи. Сведения о том, каким образом будет фиксироваться факт составления протокола должны быть отражены в нем.

Часто звучит вопрос о том, нужно ли прошивать протокол общего собрания учредителей? Ответ положительный, если в нем более одного листа. В противном случае, его прошивка не обязательна. После прошивки, с задней части протокола наклеивается заверительная надпись, на которой написано: «прошито», проставляются дата прошивки, Ф.И.О. председателя или секретаря собрания, подпись.

Скачать образец протокола общего собрания организации можно по ссылке.

Требуется ли проводить общее собрание и составлять протокол собрания учредителей, если учредитель один?

Одному учредителю нет необходимости проводить собрание, а также составлять его протокол. Это связано с тем, что он принимает решение о создании фирмы единолично, соответственно, нужды в голосовании по поставленным вопросам нет. Поскольку нет голосования, то и фиксация его результатов в протоколе не нужна.

Единственный учредитель принимает решение об учреждении организации, которое сам и подписывает. Решение юридически подменяет собой протокол общего собрания при регистрации фирмы.

Ознакомьтесь с подробной пошаговой инструкцией по регистрации ООО

Таким образом, составление протокола общего собрания учредителей ООО – важный этап при создании фирмы несколькими лицами, а порядок проведения собрания учредителей регламентируется теми же нормами, что и порядок собраний участников уже действующей организации (ст. 181.2 ГК РФ).

Протокол собрания учредителей ООО — образец 2021

Перейти к контенту

Поиск:

  • ИНДИВИДУАЛЬНЫЕ ПРЕДПРИНИМАТЕЛИ
    • Как стать ИП
      • Что нужно чтобы открыть ИП
      • Как открыть ИП в другом городе
      • Как открыть ИП на двоих
      • Можно ли работая открыть ИП
      • Как восстановить ИП
      • Правовой статус ИП
      • ИП – это физ или юр лицо
      • Что проще, зарегистрировать ИП или ООО
    • Регистрация ИП
      • Регистрация ИП пошаговая инструкция
      • Регистрация ИП иностранца
      • Образец Р21001 на регистрацию ИП
      • Госпошлина за регистрацию ИП
      • Какую систему налогообложения выбрать ИП
      • Документы для открытия ИП
    • Р24001 на смену ОКВЭД ИП
    • Закрытие ИП
      • Р26001 на закрытие ИП
      • Отчетность после закрытия ИП
    • КФХ
      • Регистрация КФХ
      • Изменение ОКВЭД КФХ
      • Смена главы КФХ
      • Как закрыть КФХ
    • Страховые взносы ИП
      • Все о страховых взносах ИП
      • Расчет взносов ИП
      • Налоги и взносы за сотрудников ИП
    • Расчетный счет для ИП
    • Печать для ИП в 2021 году
    • Выписка из ЕГРИП
    • Бухгалтерский учет ИП
  • ЮРИДИЧЕСКИЕ ЛИЦА
    • Регистрация ООО
      • Регистрация ООО пошаговая инструкция
      • Документы для регистрации ООО
      • Заявление по форме Р11001
      • Регистрация ООО иностранцем
      • Учредительные документы ООО
      • Риски при регистрации ООО
    • Смена директора ООО
    • Смена адреса ООО
    • Заявление по форме Р13001
    • Заявление по форме Р14001
    • Ликвидация ООО
      • Ликвидация ООО пошаговая инструкция
      • Как закрыть ООО с долгами
      • Уведомление о ликвидации по форме Р15001
      • Заявление о ликвидации по форме Р16001
      • Публикация о ликвидации ООО в Вестнике
      • Риски при ликвидации ООО
      • Нужен ли промежуточный ликвидационный баланс
      • Приостановка деятельности ООО без ликвидации в 2021 году
      • Реорганизация в форме присоединения
    • Банкротство
      • Ликвидация через банкротство
      • Краткий обзор процедуры банкротства
      • Взыскание задолженности с ООО, проходящего процедуру банкротства в 2021 году
    • Расчетный счет
    • Налоги и взносы за сотрудников ООО
    • Выписка из ЕГРЮЛ
    • Органы управления ООО
    • Как вести бухгалтерию ООО
  • НАЛОГООБЛОЖЕНИЕ
    • УСН
      • Все об УСН
      • Уведомление о переходе на УСН
      • Налоговая декларация по УСН
        • Все о налоговой декларации по УСН
        • Нулевая декларация по УСН
        • Декларация по УСН 6% (доходы)
        • Декларация по УСН 15% (доходы минус расходы)
        • Страховые взносы в декларации УСН
      • Право на применение УСН и его утрата
      • Бухучет ИП на УСН
      • Авансовые платежи по УСН
    • ЕНВД
      • Все об ЕНВД

Решение учредителей о создании ООО: образец протокола

Регистрация хозяйственного общества начинается с собрания учредителей. На встрече будущие партнеры обсуждают организационную форму предприятия, выбирают название и определяют основные направления деятельности. Подготовка к официальному запуску коммерческого проекта включает составление учредительных документов. Главным из них становится решение о создании ООО.

Базовые требования

Правила юридического закрепления воли собственников устанавливает статья 11 закона № 14-ФЗ от 08.02.98. В пункте втором нормы указано, что должен содержать документ:

  • наименование и организационную форму компании;
  • местонахождение;
  • факт утверждения устава;
  • избрание директора, а при наличии и членов коллегиального исполнительного органа;
  • точный размер уставного капитала.

Законодатель предусмотрел возможность создания хозяйственного общества на основе типового устава. Правительство России должно было разработать и опубликовать его в свободном доступе. Однако в 2018 году поручение не выполнено. Нормы остаются декларативными и на практике не применяются.

Важно! Легитимным решение о создании юридического лица признается при единогласном волеизъявлении. Включение участников в состав компании в принудительном порядке не допускается. Нарушение правила ведет к отклонению документов регистрирующим органом. Отказываются удостоверять такие решения и нотариусы (п. 5.9.1 письма ФНП России №2405/03-16-3 от 01.09.14).

Если в состав общества входит более 15 участников, в решении отражают факт формирования ревизионной комиссии (п.6 ст. 32 закона 14-ФЗ). Обязательным пункт будет также при включении соответствующего условия в устав фирмы.

В случае учреждения компании всего одним лицом в документе надлежит указать (абз. 3 п.2 ст. 11 закона 14-ФЗ):

  • порядок оплаты капитала ООО;
  • сроки внесения денежных средств и имущественных вкладов;
  • номинальную стоимость доли единственного собственника.

Важность включения в текст всех пунктов подтверждается постановлением ФАС Западно-Сибирского округа по спору № А27-26301/2009. Когда оформляется решение нескольких участников, правила оплаты капитала и номинальную стоимость долей согласовывают в учредительном договоре. Соглашение не представляется в налоговую службу, но обладает юридической силой.

Обязательными остаются и общие правила делопроизводства. В документе следует идентифицировать каждого учредителя. Для физлиц указывают паспортные данные и адреса постоянного проживания. Если в состав фирмы входят организации, прописать необходимо регистрационные номера, сведения о представителях. Неотъемлемым элементом являются подписи участников, дата и место проведение собрания.

Форма решения о создании общества

Типы бланков законодательно не утверждены. Парламентарии оставили за учредителями относительную свободу, утвердив лишь требования к содержанию документов. В практике применение нашли две формы.

  1. Протокол. Его оформляют при создании общества двумя участниками и более. В документе указывают повестку собрания, результаты голосования по каждому вопросу. Когда составляют протокол, опираются на стандарты делопроизводства ГОСТ (Р) 6.30-2003 и ГОСТ (Р) 7.0.97-2016.
  2. Решение. Эта форма используется в случае открытия фирмы одним лицом. Образец заполнения можно отыскать в справочно-правовых системах.

С внедрением цифровых технологий у бизнесменов появились дополнительные возможности. Если раньше решение или протокол составляли лишь на бумажном носителе, то теперь их можно формировать в электронном виде. Условием станет подписание документа квалифицированными цифровыми подписями.

Заключение

При составлении решения о создании общества участники должны руководствоваться законом 14-ФЗ от 08.02.98. В спорных вопросах следует опираться на обзоры практики ФНС России № ГД-4-14/13083 от 09.07.18 и № ГД-4-14/[email protected] от 11.10.17.

 Решение

Сетевой протокол: стандарты для обмена данными

После того, как протоколы коммутационного уровня установят основу для связи, необходим другой протокол, чтобы пакеты данных достигли соответствующих приложений. В модели OSI эта пересылка выполняется на транспортном уровне (уровень 4). У каждого стека также есть свои протоколы. Для семейства интернет-протоколов это, в частности,

  • TCP (протокол управления передачей),
  • и UDP (протокол дейтаграмм пользователя).

После большого успеха Интернета первый упомянутый протокол TCP приравнивается к IP в качестве стандарта для сетевых подключений. В большинстве случаев он строится непосредственно на IP, поэтому часто используются сети TCP / IP. Как протокол, ориентированный на соединение, TCP требует существующего соединения между пользователями связи для передачи пакетов данных . Это гарантирует надежную транспортировку данных и то, что все пакеты будут доставлены полными и в правильном порядке. Для этого протокол добавляет к данным дополнительную информацию, например порядковый номер и контрольную сумму .

UDP — это TCP аналог семейства интернет-протоколов для простой и быстрой передачи небольших пакетов данных без подключения . Соединения UDP не обеспечивают никакой безопасности для пакета, прибывающего к адресату, но из-за низкого объема административных данных (дополнительная информация в заголовке) нет явного преимущества в скорости для передачи данных, когда меньшие ошибки передачи не являются проблемой. проблема. По этой причине протокол дейтаграмм пользователя используется для потоковой передачи аудио и видео, запросов DNS и соединений VPN (виртуальная частная сеть).

Подобно семейству интернет-протоколов, другие стеки протоколов также имеют определенные протоколы передачи, основанные на их сетевых протоколах и во многом похожие на TCP. Сети Novell, например, ожидают на транспортном уровне с протоколом SPX (последовательный обмен пакетами). Со стеком AppleTalk пакеты данных можно транспортировать с использованием ATP (протокол транзакций AppleTalk).

Установление TCP-соединения — GeeksforGeeks

Установление TCP-соединения

Предварительное условие — процесс трехстороннего установления связи TCP
TCP — это протокол, ориентированный на соединение, и каждый протокол, ориентированный на соединение, должен устанавливать соединение, чтобы зарезервировать ресурсы на обоих сторонах связи.

Установление соединения —

  1. Отправитель начинает процесс следующим образом:
    • Порядковый номер (Seq = 521): содержит случайный начальный порядковый номер, который генерируется на стороне отправителя.
    • Флаг синхронизации (Syn = 1): запрашивает у приемника синхронизацию своего порядкового номера с указанным выше порядковым номером.
    • Максимальный размер сегмента (MSS = 1460 B): отправитель сообщает свой максимальный размер сегмента, так что получатель отправляет дейтаграмму, которая не требует какой-либо фрагментации.Поле MSS присутствует в поле Option в заголовке TCP.
    • Размер окна (window = 14600 B): отправитель сообщает о своей емкости буфера, в которой он должен хранить сообщения от получателя.
  2. TCP — это полнодуплексный протокол, поэтому и отправителю, и получателю требуется окно для приема сообщений друг от друга.
    • Порядковый номер (Seq = 2000): содержит случайный начальный порядковый номер, который генерируется на стороне приемника.
    • Флаг синхронизации (Syn = 1): запрашивает у отправителя синхронизацию своего порядкового номера с указанным выше порядковым номером.
    • Максимальный размер сегмента (MSS = 500 B): отправитель сообщает свой максимальный размер сегмента, так что получатель отправляет дейтаграмму, которая не требует какой-либо фрагментации. Поле MSS присутствует в поле Option в заголовке TCP.
      Поскольку получатель MSS <отправитель MSS , обе стороны соглашаются использовать минимальный MSS, то есть 500 Б, чтобы избежать фрагментации пакетов на обоих концах.
      Таким образом, получатель может отправить максимум 14600/500 = 29 пакетов.
      Это размер окна отправки получателя. 
    • Размер окна (окно = 10000 Б): получатель сообщает о своей емкости буфера, в которой он должен хранить сообщения от отправителя.
      Следовательно, отправитель может отправить максимум 10000/500 = 20 пакетов.
      Это размер окна отправки отправителя. 
    • Номер подтверждения (Ack no. = 522): Поскольку получатель получает порядковый номер 521, он запрашивает следующий порядковый номер с Ack no.= 522, который является следующим пакетом, ожидаемым получателем, поскольку флаг Syn использует 1 номер последовательности.
    • Флаг ACK (ACk = 1): сообщает, что поле номера подтверждения содержит следующую последовательность, ожидаемую получателем.


  3. Отправитель дает окончательный ответ об установлении соединения следующим образом:
    • Порядковый номер (Seq = 522): , поскольку порядковый номер = 521 на этапе 1 и флаг SYN использует один порядковый номер, следовательно, следующий порядковый номер будет 522.
    • Номер подтверждения (Ack no. = 2001): , поскольку отправитель подтверждает пакет SYN = 1 от получателя с порядковым номером 2000, поэтому следующий ожидаемый порядковый номер — 2001.
    • Флаг ACK (ACK = 1): сообщает, что поле номера подтверждения содержит следующую последовательность, ожидаемую отправителем.


Поскольку фаза установления соединения TCP использует 3 пакета, это также известно как 3-стороннее подтверждение связи (SYN, SYN + ACK, ACK).

Следующая статья по теме — Завершение TCP-соединения

Вниманию читателя! Не прекращайте учиться сейчас. Ознакомьтесь со всеми важными концепциями теории CS для собеседований SDE с помощью курса CS Theory Course по доступной для студентов цене и будьте готовы к отрасли.

Пакет протоколов 29.0.0 — Протоколы: H [Поддержка]

Имя / ключевое слово CLI

х423

Полный Название

H.323 Протокол

Описание

H.323 — это рекомендация Сектора стандартизации электросвязи МСЭ (ITU-T) который определяет протоколы для обеспечения сеансов аудиовизуальной связи на любая пакетная сеть. Стандарт H.323 касается сигнализации и управления вызовом, мультимедийный транспорт и управление, а также управление полосой пропускания для двухточечных и многоточечные конференции.

Номер ссылки

http: / / www.h423forum.org/

Глобальный ID

L7: 64

ID

64

Известно Отображения

Порт UDP

1300,1718,1719,1720,11720

TCP-порт

1300,1718,1719,1720,11720

IP Протокол

IP Версия

IPv4 Служба поддержки

Да

IPv6 Служба поддержки

Да

Группа приложений

другое

Актуальность для бизнеса

актуально для бизнеса.Начиная с Cisco IOS XE 3.16S и IOS 15.5 (3) M только.

Категория

голос и видео

Sub Категория

контрольно-сигнализационная

P2P Технологии

Нет

Зашифрованный

Нет

Класс трафика

сигнализация.Только с Cisco IOS XE 3.16S и IOS 15.5 (3) M.

Тоннель

Нет

Базовые протоколы

RFC 4572 — Медиа-транспорт с установлением соединения по протоколу TLS в протоколе описания сеанса (SDP)

[Документы] [txt | pdf] [draft-ietf-mmus…] [Tracker] [Diff1] [Diff2]

Устарело: 8122 ПРЕДЛАГАЕМЫЙ СТАНДАРТ
Сетевая рабочая группа Дж. Леннокс
Запрос комментариев: 4572 Columbia U.
Обновления: 4145 июль 2006 г.
Категория: Трек стандартов


 Транспорт мультимедиа с установлением соединения через безопасность транспортного уровня
        (TLS) Протокол в протоколе описания сеанса (SDP)

Статус этой памятки

   Этот документ определяет протокол отслеживания стандартов Интернета для
   Интернет-сообщество и просит обсуждения и предложения по
   улучшения.Пожалуйста, обратитесь к текущему выпуску "Интернет
   Официальные стандарты протокола »(STD 1) для состояния стандартизации
   и статус этого протокола. Распространение памятки не ограничено.

Уведомление об авторских правах

   Авторское право (C) The Internet Society (2006).

Аннотация

   Этот документ определяет, как установить безопасное соединение, ориентированное на
   сеансы передачи мультимедиа через Transport Layer Security (TLS)
   протокол с использованием протокола описания сеанса (SDP). Он определяет
   новый идентификатор протокола SDP, «TCP / TLS».Он также определяет синтаксис
   и семантика для атрибута «отпечаток пальца» SDP, который идентифицирует
   сертификат, который будет представлен для сеанса TLS. Этот
   механизм позволяет передавать мультимедиа по TLS-соединениям
   установлено безопасно, пока целостность сеанса
   описания гарантировано.

   Этот документ расширяет и обновляет RFC 4145.

















Дорожка стандартов Lennox [Страница 1] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


Содержание

   1.Введение ................................................. ... 3
   2. Терминология ............................................... ...... 4
   3. Обзор ............................................... ......... 4
      3.1. Рабочие режимы SDP ...................................... 4
      3.2. Модель угрозы ............................................... 5
      3.3. Потребность в самозаверяющих сертификатах ..................... 5
      3.4. Пример описания SDP для TLS-соединения ................. 6
   4. Идентификаторы протокола ............................................ 6
   5. Атрибут отпечатка пальца ........................................... 7
   6. Идентификация конечной точки ......................................... 9
      6.1. Выбор сертификата ......................................... 9
      6.2. Вручение сертификата .................................. 10
   7. Соображения безопасности ........................................ 10
   8. Вопросы IANA ............................................ 12
   9. Ссылки ............................................... ...... 14
      9.1. Нормативные ссылки ...................................... 14
      9.2. Информационные ссылки .................................... 15
































Программа стандартов Lennox [Страница 2] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


1. Введение

   Протокол описания сеанса (SDP) [1] обеспечивает универсальный
   формат описания мультимедийных сеансов в объявлениях или
   приглашения.Для многих приложений желательно установить, как
   часть мультимедийного сеанса, медиапоток, который использует соединение -
   ориентированный транспорт. RFC 4145, Транспорт мультимедиа с установлением соединения в
   протокол описания сеанса (SDP) [2], определяет общий
   механизм описания и установления таких ориентированных на соединение
   ручьи; однако единственный транспортный протокол, который он поддерживает напрямую, это
   TCP. Во многих случаях участники сеанса хотят предоставить
   конфиденциальность, целостность данных и аутентификация для их носителей
   сессий.Таким образом, этот документ расширяет ориентированный на соединение
   Спецификация медиа, позволяющая описанию сеанса описывать медиа
   сеансы, использующие протокол безопасности транспортного уровня (TLS) [3].

   Протокол TLS позволяет приложениям общаться по каналу
   что обеспечивает конфиденциальность и целостность данных. TLS
   спецификация, однако, не указывает, как конкретные протоколы
   установить и использовать этот защищенный канал; в частности, TLS оставляет
   вопрос о том, как интерпретировать и проверять сертификаты аутентификации
   как проблема для протоколов, работающих через TLS.Этот документ
   определяет такое использование для случая среды с установлением соединения
   транспорт.

   Эта проблема усложняется тем, что конечные точки, обменивающиеся медиа, часто
   невозможно получить сертификаты аутентификации, подписанные известным
   корневой центр сертификации (ЦС). Большинство центров сертификации
   плата за подписанные сертификаты, особенно сертификаты хоста;
   кроме того, существуют значительные административные накладные расходы на
   получение подписанных сертификатов, поскольку удостоверяющие центры должны быть
   могут подтвердить, что они выдают подписанные сертификаты на
   правильная партия.Кроме того, во многих случаях IP-адреса конечных точек
   и имена хостов являются динамическими: они могут быть получены от DHCP для
   пример. Получать действительный сертификат, подписанный ЦС, непрактично.
   на время аренды DHCP. Для таких хостов самоподписанные
   сертификаты обычно являются единственным вариантом. Эта спецификация определяет
   механизм, позволяющий использовать самоподписанные сертификаты
   безопасно, при условии, что целостность описания SDP
   уверен. Это позволяет конечным точкам включать безопасный хэш своих
   сертификат, известный как «отпечаток сертификата», в
   описание сеанса.При условии, что отпечаток предложенного
   сертификат совпадает с сертификатом в описании сеанса, конечные хосты могут
   доверяйте даже самоподписанным сертификатам.

   Остальная часть этого документа представлена ​​следующим образом. Обзор
   модель проблемы и угрозы представлена ​​в разделе 3. В разделе 4 приведены
   базовый механизм для создания подключенных медиа на основе TLS



Программа стандартов Lennox [Страница 3] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


   в SDP.В разделе 5 описывается атрибут отпечатка SDP, который,
   предполагая, что целостность содержимого SDP гарантирована, позволяет
   безопасное использование самозаверяющих сертификатов. Раздел 6 описывает, какие
   Представлены сертификаты X.509 и их использование в TLS.
   В разделе 7 обсуждаются дополнительные соображения безопасности.

2. Терминология

   В этом документе ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО»,
   «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ»,
   и «ДОПОЛНИТЕЛЬНО» следует интерпретировать, как описано в RFC 2119 [4] и
   укажите уровни требований для совместимых реализаций.3. Обзор

   В этом разделе обсуждается модель угроз, которая мотивирует транспорт TLS.
   для медиапотоков с установлением соединения. Он также обсуждает более
   подробно описать необходимость использования конечными системами самозаверяющих сертификатов.

3.1. Рабочие режимы SDP

   Существует два основных режима работы мультимедийных сеансов:
   рекламируется и предлагает-ответ. Рекламируемые сеансы проще
   Режим. В этом режиме сервер каким-то образом публикует SDP
   описание сеанса мультимедийного сеанса, который он делает доступным.Классическим примером этого режима работы является сеанс
   Протокол объявлений (SAP) [15], в котором описания сеансов SDP
   периодически передаются в известную группу многоадресной рассылки.
   Традиционно эти описания включают многоадресные конференции, но
   также возможны одноадресные сеансы. (СМИ, ориентированные на подключение,
   очевидно, не может использовать многоадресную рассылку.) Получатели сеанса
   описание подключиться к адресам, опубликованным в сеансе
   описание. Эти получатели, возможно, ранее не были известны
   Рекламодатель описания сеанса.В качестве альтернативы конференции SDP могут работать в режиме предложение-ответ [5].
   Этот режим позволяет двум участникам мультимедийного сеанса
   согласовывать мультимедийный сеанс между ними. В этой модели один
   участник предлагает другому описание желаемого сеанса
   с его точки зрения, а другой участник отвечает
   желаемый сеанс с его точки зрения. В этом режиме каждый из
   участники сеанса знают о другом. Это
   режим работы, используемый протоколом инициации сеанса (SIP)
   [16].Дорожка стандартов Lennox [Страница 4] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


3.2. Модель угрозы

   Участники мультимедийных конференций часто хотят гарантировать
   конфиденциальность, целостность данных и аутентификация для их носителей
   сессий. В этом разделе описаны различные типы злоумышленников и
   способы, которыми они пытаются нарушить эти гарантии. Затем он описывает, как
   протокол TLS может быть использован для предотвращения атак злоумышленников.Самый простой тип злоумышленника - это тот, кто пассивно слушает
   трафик, связанный с мультимедийным сеансом. Этот злоумышленник может,
   например, находиться в той же локальной или беспроводной сети, что и один из
   участники конференции. Этот тип злоумышленников не
   угрожают целостности данных или аутентификации соединения и почти
   любой режим работы TLS может обеспечить конфиденциальность медиапотока.

   Более изощренным является злоумышленник, который может отправлять собственный трафик данных.
   по сети, но не может изменять или перенаправлять действительный трафик.В «объявленном» рабочем режиме SDP это едва ли можно рассматривать
   атака; ожидается, что медиа-сессии будут инициированы откуда угодно
   в сети. Однако в режиме предложения-ответа SDP этот тип
   приступ более серьезный. Злоумышленник может инициировать подключение к
   одна или обе конечные точки сеанса, таким образом выдавая себя за
   конечной точки, или действовать как мужчина посередине, чтобы подслушивать их
   коммуникации. Чтобы предотвратить эти атаки, TLS использует конечную точку.
   сертификаты.Пока закрытые ключи сертификатов не
   были скомпрометированы, конечные точки имеют внешний доверенный механизм
   (чаще всего это взаимно доверенный центр сертификации)
   проверять сертификаты, и конечные точки знают, какой сертификат
   идентичность, чтобы ожидать, конечные точки могут быть уверены, что такая атака имеет
   не состоялось.

   Наконец, самый серьезный тип злоумышленников - это тот, кто может изменить или
   описания сеансов перенаправления: например, скомпрометированный или
   вредоносный прокси-сервер SIP.Ни сам TLS, ни какие-либо механизмы
   которые его используют, могут защитить сеанс SDP от такого злоумышленника.
   Вместо этого само описание SDP должно быть защищено некоторыми
   механизм; SIP, например, определяет, как S / MIME [17] может использоваться для
   описания безопасных сеансов.

3.3. Потребность в самозаверяющих сертификатах

   Описания сеансов SDP создаются любой конечной точкой, которая должна
   участвовать в мультимедийной сессии. Во многих случаях, например, SIP
   телефоны, такие конечные точки имеют динамически настраиваемые IP-адреса и
   имена хостов и должны быть развернуты с почти нулевой конфигурацией.За
   такой конечной точки, для практических целей невозможно получить
   сертификат, подписанный известным центром сертификации.




Дорожка стандартов Lennox [Страница 5] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


   Если две конечные точки не имеют предыдущих отношений, самозаверяющие сертификаты
   обычно нельзя доверять, поскольку нет гарантии, что
   злоумышленник не запускает атаку "человек посередине".К счастью,
   однако, если целостность описаний сеансов SDP может быть гарантирована,
   эти описания SDP можно рассматривать как
   предыдущие отношения: сертификаты могут быть безопасно описаны в
   само описание сеанса. Это делается путем предоставления безопасного хеша
   сертификата или «отпечатка сертификата» в качестве атрибута SDP;
   этот механизм описан в разделе 5.

3.4. Пример описания SDP для TLS-соединения

   На рисунке 1 показано предложение SDP, которое сигнализирует о доступности
   Т.38 факсов через TLS. Для краткости основной
   часть описания сеанса опущена в примере, показывая
   только линия "m" и ее атрибуты. (Этот пример такой же, как
   первый в RFC 4145 [2], за исключением параметра proto и
   атрибут отпечатка пальца.) См. пояснения в следующих разделах.
   атрибутов примера TLS.

   (Примечание: из-за соглашений о форматировании RFC этот документ разделяет SDP
   через строки, содержание которых превышает 72 символа.Обратная косая черта
   знаки, в которых произошел перенос строки. Этот
   обратная косая черта и ее конечный CRLF и пробел не будут отображаться в
   фактическое содержание SDP.)

   m = изображение 54111 TCP / TLS t38
   c = В IP4 192.0.2.2
   a = настройка: пассивный
   a = соединение: новое
   a = отпечаток пальца: SHA-1 \
          4A: AD: B9: B1: 3F: 82: 18: 3B: 54: 02: 12: DF: 3E: 5D: 49: 6B: 19: E5: 7C: AB

       Рисунок 1: Пример описания SDP, предлагающего медиапоток TLS

4. Идентификаторы протокола

   Строка 'm' в SDP указывает, среди прочего, транспорт
   протокол, который будет использоваться для медиа в сеансе.Смотрите "СМИ
   Раздел описания SDP [1] для обсуждения транспорта
   идентификаторы протокола.

   Эта спецификация определяет новый идентификатор протокола «TCP / TLS»,
   что указывает на то, что описанный носитель будет использовать транспортный уровень.
   Протокол безопасности [3] поверх TCP. (Использование TLS поверх другого транспорта
   протоколы не обсуждаются в этом документе.) Протокол TCP / TLS
   идентификатор описывает только транспортный протокол, а не верхний уровень
   протокол. Строка 'm', которая указывает 'TCP / TLS', ДОЛЖНА дополнительно квалифицироваться.



Программа стандартов Lennox [Страница 6] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


   протокол, использующий идентификатор FMT, чтобы указать, что приложение
   запустить TLS.Медиа-сеансы, описанные с помощью этого идентификатора, следуют процедурам
   определено в RFC 4145 [2]. Они также используют атрибуты SDP, определенные в
   эта спецификация, «настройка» и «соединение».

5. Атрибут отпечатка пальца

   Участники сеанса TLS указывают свою личность, представляя
   сертификаты аутентификации как часть процедуры подтверждения TLS.
   Сертификаты аутентификации - это сертификаты X.509 [6], как профилированные.
   согласно RFC 3279 [7], RFC 3280 [8] и RFC 4055 [9].

   Чтобы связать медиапотоки с соединениями и предотвратить
   несанкционированные атаки с вторжением на медиапотоки, конечные точки ДОЛЖНЫ
   предоставить отпечаток сертификата.Если сертификат X.509
   представленный для TLS-соединения соответствует отпечатку пальца, представленному в
   SDP, конечная точка может быть уверена, что автор SDP
   собственно инициатор подключения.

   Отпечаток сертификата - это безопасный односторонний хэш DER
   (отличительные правила кодирования) форма сертификата. (Сертификат
   отпечатки пальцев широко поддерживаются инструментами, которые манипулируют X.509
   сертификаты; например, команда "openssl x509 -fingerprint"
   заставляет инструмент командной строки пакета openssl печатать
   отпечаток сертификата, а менеджеры сертификатов для Mozilla и
   Internet Explorer отображает их при просмотре деталей
   сертификат.)

   Отпечаток пальца представлен в SDP как атрибут (линия «а»).
   Он состоит из имени используемой хеш-функции, за которым следует
   само значение хеш-функции. Хеш-значение представлено как последовательность
   прописные шестнадцатеричные байты, разделенные двоеточиями. Номер
   bytes определяется хеш-функцией. (Это синтаксис, используемый
   openssl и менеджеры сертификатов браузеров. Это отличается
   из синтаксиса, используемого для представления хеш-значений, например, в дайджесте HTTP
   аутентификация [18], в которой используются строчные шестнадцатеричные без разделителей.
   байты.Было отмечено, что согласованность с другими приложениями
   отпечатки пальцев были важнее.)

   Формальный синтаксис атрибута отпечатка пальца приведен в расширенном
   Форма Бэкуса-Наура [10] на рисунке 2. Этот синтаксис расширяет BNF.
   синтаксис SDP [1].







Дорожка стандартов Lennox [Страница 7] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


   attribute = / fingerprint-attribute

   fingerprint-attribute = "fingerprint" ":" hash-func SP отпечаток пальца

   hash-func = "sha-1" / "sha-224" / "sha-256" /
                             "ша-384" / "ша-512" /
                             «md5» / «md2» / токен
                             ; Дополнительные хеш-функции могут прийти только
                             ; из обновлений RFC 3279

   fingerprint = 2UHEX * (":" 2UHEX)
                             ; Каждый байт в шестнадцатеричном формате в верхнем регистре, разделенный
                             ; двоеточиями.UHEX = ЦИФРА /% x41-46; A-F прописные буквы

   Рисунок 2: Расширенный синтаксис Бэкуса-Наура для атрибута отпечатка пальца

   Отпечаток сертификата ДОЛЖЕН быть вычислен с использованием того же одностороннего
   хэш-функция, которая используется в алгоритме подписи сертификата.
   (Это гарантирует, что свойства безопасности, необходимые для
   сертификат также применяется для отпечатка пальца. Это также гарантирует, что
   отпечаток пальца будет использоваться другой конечной точкой, пока
   Сам сертификат есть.) После RFC 3279 [7], обновленного RFC
   4055 [9], следовательно, определены хэш-функции «SHA-1» [11]
   [19], «SHA-224» [11], «SHA-256» [11], «SHA-384» [11], «SHA-512» [11],
   «MD5» [12] и «MD2» [13], предпочтительно «SHA-1». Новый IANA
   реестр текстовых имен хеш-функций, указанный в разделе 8,
   позволяет добавлять будущие токены, но они могут быть добавлены только в том случае, если
   они включены в RFC, обновляющие или устаревшие RFC 3279 [7].
   Самозаверяющие сертификаты (для которых устаревшие сертификаты не являются
   рассмотрение) ДОЛЖЕН использовать один из алгоритмов FIPS 180 (SHA-1,
   SHA-224, SHA-256, SHA-384 или SHA-512) в качестве алгоритма подписи,
   и, следовательно, также ДОЛЖЕН использовать его для вычисления отпечатков сертификатов.Атрибут отпечатка пальца может быть либо сеансовым, либо мультимедийным.
   атрибут уровня SDP. Если это атрибут уровня сеанса, он применяется
   ко всем сеансам TLS, для которых не указан атрибут отпечатка на уровне носителя.
   определены.












Дорожка стандартов Lennox [Страница 8] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


6. Идентификация конечной точки

6.1. Выбор сертификата

   Сертификат X.509 связывает личность и открытый ключ.Если SDP
   описание сеанса TLS передается через механизм, который
   обеспечивает защиту целостности, сертификат, подтверждающий любые
   МОЖЕТ использоваться синтаксически действительный идентификатор. Например, SDP
   описание, отправленное по HTTP / TLS [20] или защищенное S / MIME [17], МОЖЕТ
   подтвердить любую личность в сертификате, защищающем медиа-соединение.

   Протоколы безопасности, обеспечивающие только пошаговую защиту целостности
   (например, протокол sips [16], SIP через TLS) считаются
   достаточно безопасен, чтобы разрешить режим, в котором любая действительная личность
   принятый.Тем не менее, см. Раздел 7 для обсуждения некоторых вопросов безопасности.
   последствия этого факта.

   Однако в ситуациях, когда SDP не защищен целостностью,
   сертификат, предоставленный для TLS-соединения, ДОЛЖЕН сертифицировать соответствующий
   личность для подключения. В этих сценариях сертификат
   представленный конечной точкой ДОЛЖЕН подтвердить либо соединение SDP
   адрес или личность создателя сообщения SDP, как
   следует:

   o Если указан адрес подключения для описания носителя
      в качестве IP-адреса конечная точка МОЖЕТ использовать сертификат с
      iPAddress subjectAltName, который точно соответствует IP в
      адрес подключения в строке "c" описания сеанса.Точно так же, если адрес подключения для описания мультимедиа
      указанное как полное доменное имя, конечная точка МОЖЕТ использовать
      сертификат с dNSName subjectAltName, соответствующим указанному
      Точно адрес соединения строки 'c'. (Шаблоны подстановки НЕ ДОЛЖНЫ
      использоваться.)

   o В качестве альтернативы, если описание сеанса SDP для сеанса было
      передается по протоколу (например, SIP [16]), для которого
      идентичности участников сеанса определяются единым ресурсом
      идентификаторы (URI), конечная точка МОЖЕТ использовать сертификат с
      uniformResourceIdentifier subjectAltName, соответствующий
      идентификатор конечной точки, создавшей SDP.Детали
      действительные URI зависят от протокола передачи.
      (Дополнительные сведения о действительности URI см. В разделе 7.)

   Сопоставление идентификаторов выполняется с использованием правил сопоставления, указанных в
   RFC 3280 [8]. Если присутствует более одного идентификатора данного типа
   в сертификате (например, более одного имени dNSName) совпадение в любом
   один из набора считается приемлемым. Для поддержки использования
   кеши сертификатов, как описано в разделе 7, конечным точкам СЛЕДУЕТ



Дорожка стандартов Lennox [Страница 9] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


   последовательно предоставлять один и тот же сертификат для каждой личности, которую они
   служба поддержки.6.2. Вручение сертификата

   Во всех случаях конечная точка, действующая как сервер TLS (т. Е. Принимающая
   роль "настройка: пассивная" в терминологии ориентированного на соединение
   media) ДОЛЖЕН предоставить сертификат во время инициации TLS, после
   правила, представленные в разделе 6.1. Если сертификат не
   соответствует исходному отпечатку пальца, конечная точка клиента ДОЛЖНА завершиться
   медиа-соединение с ошибкой bad_certificate.

   Если используется модель предложения / ответа SDP [5], клиент (
   конечная точка с ролью 'setup: active') ДОЛЖНА также представлять
   сертификат по правилам Раздела 6.1. Сервер ДОЛЖЕН
   запросить сертификат, и если клиент его не предоставляет, или если
   сертификат не соответствует предоставленному отпечатку пальца, сервер
   конечная точка ДОЛЖНА разорвать медиа-соединение с помощью bad_certificate
   ошибка.

   Обратите внимание, что при использовании модели предложение / ответ возможно
   чтобы медиа-соединение опередило ответ оферента.
   Таким образом, если оферент предложил 'setup: passive' или 'setup: actpass'
   роль, он ДОЛЖЕН (как указано в RFC 4145 [2]) начать прослушивание
   входящее соединение, как только оно отправит свое предложение.Однако он ДОЛЖЕН
   НЕ предполагать, что данные, передаваемые по TLS-соединению, действительны
   пока он не получит соответствующий отпечаток пальца в ответе SDP. Если
   полученный отпечаток пальца не соответствует отпечатку пальца клиента.
   сертификат, конечная точка сервера ДОЛЖНА разорвать медиа-соединение
   с ошибкой bad_certificate, как указано в предыдущем абзаце.

   Если предложение / ответ не используется (например, если SDP был отправлен через
   Session Announcement Protocol [15]), безопасного канала нет.
   доступны для клиентов, чтобы передать отпечатки сертификатов
   серверы.В этом случае серверы МОГУТ запрашивать сертификаты клиентов,
   которые ДОЛЖНЫ быть подписаны известным центром сертификации, или
   МОЖЕТ позволить клиентам подключаться без сертификата.

7. Соображения безопасности

   Весь этот документ касается безопасности. Проблема в
   решается в разделе 1, а общий обзор
   представлен в разделе 3. См. спецификацию SDP [1] для безопасности
   соображения, применимые к SDP в целом.

   Предложение TCP / TLS-соединения в SDP (или согласование его в SDP
   режим предложения / ответа) не обязывает конечную точку
   принимать любое соединение TLS с данным отпечатком пальца.Вместо этого



Дорожка стандартов Lennox [Страница 10] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


   конечная точка должна участвовать в стандартной процедуре согласования TLS, чтобы
   убедитесь, что выбранный шифр потока TLS и алгоритм MAC соответствуют
   потребности безопасности приложения более высокого уровня. (Например,
   предлагаемый потоковый шифр TLS_NULL_WITH_NULL_NULL ДОЛЖЕН быть отклонен
   практически в каждом сценарии применения.)

   Как и все сообщения SDP, сообщения SDP, описывающие потоки TLS, являются
   передается в протоколе инкапсулирующего приложения (например, SIP, Media
   Протокол управления шлюзом (MGCP) и т. Д.). Это ответственность
   протокол инкапсуляции для обеспечения целостности SDP
   описания безопасности. Следовательно, протокол приложения ДОЛЖЕН
   либо задействовать свои собственные механизмы безопасности (например, безопасные составные части)
   или, в качестве альтернативы, использовать службу безопасности нижнего уровня (например, TLS
   или IPsec).Эта служба безопасности ДОЛЖНА обеспечивать надежное сообщение
   аутентификация, а также эффективная защита от воспроизведения.

   Однако такая защита целостности не всегда возможна. Для этих
   случаях конечным системам СЛЕДУЕТ поддерживать кэш сертификатов, которые другие
   стороны ранее представили использование этого механизма. Если возможно,
   пользователи ДОЛЖНЫ получать уведомления, когда незащищенный сертификат связан
   с ранее неизвестной конечной системой и ДОЛЖЕН быть
   строго предупрежден, если другой незащищенный сертификат представлен
   сторона, с которой они общались в прошлом.Таким образом,
   даже при отсутствии защиты целостности для SDP безопасность
   механизм этого документа эквивалентен Secure Shell
   (ssh) протокол [21], который уязвим для атак типа "злоумышленник посередине".
   когда две стороны впервые общаются, но могут обнаружить те, которые происходят
   впоследствии. (Обратите внимание, что точное определение «другой стороны»
   зависит от протокола приложения, передающего сообщение SDP.) Пользователи
   Тем не менее, НЕ СЛЕДУЕТ получать уведомления о
   сертификаты, описанные в описаниях SDP, отправленные через целостность-
   защищенный канал.Чтобы способствовать взаимодействию и развертыванию, протоколы безопасности, которые
   обеспечивать только защиту целостности по шагам (например, протокол sips
   [16], SIP через TLS) считаются достаточно безопасными, чтобы позволить
   режим, в котором любая синтаксически допустимая идентичность принимается в
   сертификат. Это решение было принято, потому что в настоящее время
   механизм целостности, который, скорее всего, будет использоваться в развернутых сетях в
   в краткосрочной и среднесрочной перспективе. Однако в этом режиме целостность SDP
   уязвимы для атак со стороны скомпрометированных или вредоносных промежуточных ящиков, e.г.,
   Прокси-серверы SIP. Конечные системы МОГУТ предупреждать пользователей о сеансах SDP
   которые защищены только поэтапно, и определения
   форматы мультимедиа, работающие по TCP / TLS, МОГУТ указывать, что только сквозной
   механизмы целостности.






Дорожка стандартов Lennox [Страница 11] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


   В зависимости от того, как передаются сообщения SDP, это не всегда
   можно определить, присутствует ли subjectAltName в
   удаленный сертификат ожидается для удаленной стороны.В частности,
   с учетом переадресации вызовов, стороннего управления вызовами или сеанса
   описания, генерируемые конечными точками, управляемыми Gateway Control
   Протокол [22], в SIP не всегда можно определить, что
   объект должен был сгенерировать удаленный ответ SDP. В общем,
   когда не используется защита подлинности и целостности SDP
   описания, сертификат, передаваемый через SIP, ДОЛЖЕН подтверждать
   SIP-адрес записи конечной точки как uniformResourceIndicator
   subjectAltName.Когда конечная точка получает сертификат по SIP
   утверждение личности (включая идентификатор iPAddress или dNSName)
   кроме того, которому он позвонил или получил вызов, он ДОЛЖЕН
   предупредить пользователя и запросить подтверждение. Это применимо независимо от того,
   сертификаты самозаверяющие или подписанные центрами сертификации;
   сертификат для sip: [email protected] может быть законно подписан
   центр сертификации, но все еще может быть неприемлемым для звонка
   потягивать: alice @ example.com. (Эта проблема не связана с этим
   Спецификация; то же самое относится и к SDP, подписанному S / MIME
   переносится через SIP.)

   Этот документ не определяет никаких механизмов для безопасной транспортировки
   Пакеты RTP и RTP Control Protocol (RTCP) по
   канал, ориентированный на соединение. Консенсуса в работе не было.
   группа относительно того, лучше ли отправлять пакеты Secure RTP
   [23] по ориентированному на соединение транспорту [24], или
   лучше отправлять стандартные незащищенные пакеты RTP через TLS, используя
   механизмы, описанные в этом документе.Групповой консенсус состоял в том, чтобы
   подождите, пока вариант использования, требующий безопасного подключения RTP, не будет
   представлены.

   TLS не всегда является наиболее подходящим выбором для безопасного соединения.
   ориентированные СМИ; в некоторых случаях безопасность более высокого или низкого уровня
   протокол может быть подходящим.

8. Соображения IANA

   Этот документ определяет значение протокола SDP: «TCP / TLS». Его формат
   определено в разделе 4. Это значение прототипа зарегистрировано IANA
   в разделе «Параметры протокола описания сеанса (SDP)» в разделе «Протокол».Этот документ определяет сеанс SDP и атрибут уровня мультимедиа:
   «отпечаток пальца». Его формат определен в Разделе 5. Этот атрибут
   был зарегистрирован IANA в разделе "Протокол описания сеанса (SDP)"
   Параметры "под" полем att (как сеанс, так и уровень мультимедиа) ".

   В спецификации SDP [1] указано, что спецификации, определяющие новые
   значения proto, такие как значение протокола TCP / TLS, определенное в этом,



Дорожка стандартов Lennox [Страница 12] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


   должны определять правила, по которым их пространство имен медиа-формата (fmt)
   удалось.Для протокола TCP / TLS новые форматы ДОЛЖНЫ иметь
   связанная регистрация MIME. Использование существующего подтипа MIME для
   формат приветствуется. Если подтипа MIME не существует, это
   РЕКОМЕНДУЕТСЯ зарегистрировать подходящий через IETF.
   процесс [14] путем создания или ссылки на стандарты RFC
   который определяет транспортный протокол для формата.

   Эта спецификация создает новый реестр IANA под названием «Хэш-функция.
   Текстовые имена ". Это не будет частью параметров SDP.Имена хэш-функций, используемых для отпечатков сертификатов:
   зарегистрирован IANA. Хеш-функции ДОЛЖНЫ быть определены стандартами -
   отслеживать RFC, обновляющие или устаревшие RFC 3279 [7].

   При регистрации нового текстового имени хэш-функции следующие
   информация ДОЛЖНА быть предоставлена:

   o Текстовое имя хэш-функции.

   o Идентификатор объекта (OID) хэш-функции, используемый в X.509.
      сертификаты.

   o Ссылка на RFC для отслеживания стандартов, обновление или устаревание RFC
      3279 [7], определяющий использование хеш-функции в X.509
      сертификаты.

   На рисунке 3 показаны начальные значения этого реестра.

   Ссылка на OID имени хеш-функции
   ------------------ --- ---------
   "md2" 1.2.840.113549.2.2 RFC 3279
   "md5" 1.2.840.113549.2.5 RFC 3279
   "sha-1" 1.3.14.3.2.26 RFC 3279
   "sha-224" 2.16.840.1.101.3.4.2.4 RFC 4055
   «Ша-256» 2.16.840.1.101.3.4.2.1 RFC 4055
   "sha-384" 2.16.840.1.101.3.4.2.2 RFC 4055
   "sha-512" 2.16.840.1.101.3.4.2.3 RFC 4055

            Рисунок 3: Реестр текстовых имен функций хеширования IANA











Дорожка стандартов Lennox [Страница 13] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


9. Ссылки

9.1. Нормативные ссылки

   [1] Хэндли, М., Якобсон, В., и К. Перкинс, "SDP: сессия
         Описание протокола », RFC 4566, июль 2006 г.[2] Йон, Д. и Дж. Камарилло, "Транспорт мультимедиа на основе TCP в
         Протокол описания сеанса (SDP) », RFC 4145, сентябрь 2005 г.

   [3] Диркс, Т. и Э. Рескорла, "Безопасность транспортного уровня (TLS)
         Версия протокола 1.1 », RFC 4346, апрель 2006 г.

   [4] Брэднер, С. «Ключевые слова для использования в RFC для обозначения требований.
         Уровни », BCP 14, RFC 2119, март 1997 г.

   [5] Розенберг, Дж. И Х. Шульцринн, "Модель предложения / ответа с
         Протокол описания сеанса (SDP) », RFC 3264, июнь 2002 г.[6] Международный союз электросвязи, «Информационные технологии.
         - Взаимодействие открытых систем - Справочник: открытый ключ и
         структуры сертификатов атрибутов », Рекомендация МСЭ-Т X.509,
         Стандарт ISO 9594-8, март 2000 г.

   [7] Бассхэм, Л., Полк, В., и Р. Хаусли, "Алгоритмы и
         Идентификаторы для инфраструктуры открытых ключей Internet X.509
         Сертификат и профиль отзыва сертификатов (CRL) ",
         RFC 3279, апрель 2002 г.

   [8] Хаусли Р., Полк, В., Форд, В. и Д. Соло, Internet X.509
         Сертификат и сертификат инфраструктуры открытого ключа
         Профиль отзываемых списков (CRL) », RFC 3280, апрель 2002 г.

   [9] Шаад, Дж., Калиски, Б., и Р. Хаусли, "Дополнительные алгоритмы
         и идентификаторы для криптографии RSA для использования в Интернете
         Сертификат и сертификат инфраструктуры открытого ключа X.509
         Профиль отзываемых списков (CRL) », RFC 4055, июнь 2005 г.

   [10] Крокер, Д. и П. Оверелл, «Расширенный BNF для синтаксиса.
         Спецификации: ABNF », RFC 4234, октябрь 2005 г.[11] Национальный институт стандартов и технологий, Secure Hash
         Стандарт », FIPS PUB 180-2, август 2002 г., .

   [12] Ривест Р., "Алгоритм дайджеста сообщений MD5", RFC 1321,
         Апрель 1992 г.




Дорожка стандартов Lennox [Страница 14] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


   [13] Калиски Б., "Алгоритм дайджеста сообщений MD2", RFC 1319,
         Апрель 1992 г.[14] Фрид, Н. и Дж. Кленсин, "Спецификации типа носителя и
         Процедуры регистрации », BCP 13, RFC 4288, декабрь 2005 г.

9.2. Информативные ссылки

   [15] Хэндли, М., Перкинс, К., и Э. Уилан, "Объявление о сессии
         Протокол », RFC 2974, октябрь 2000 г.

   [16] Розенберг, Дж., Шульцринн, Х., Камарилло, Г., Джонстон, А.,
         Петерсон, Дж., Спаркс, Р., Хэндли, М., и Э. Шулер, "SIP:
         Протокол инициации сеанса », RFC 3261, июнь 2002 г.

   [17] Рамсделл Б., "Безопасные / многоцелевые расширения почты Интернета
         (S / MIME) Версия 3.1 Спецификация сообщений ", RFC 3851, июль
         2004 г.

   [18] Фрэнкс, Дж., Халлам-Бейкер, П., Хостетлер, Дж., Лоуренс, С.,
         Лич П., Луотонен А. и Л. Стюарт, «HTTP-аутентификация:
         Базовая и дайджест-проверка подлинности доступа », RFC 2617, июнь 1999 г.

   [19] Истлейк Д. и П. Джонс, "Безопасный алгоритм хеширования 1 США (SHA1)",
         RFC 3174, сентябрь 2001 г.

   [20] Рескорла Э., «HTTP через TLS», RFC 2818, май 2000 г.[21] Илонен, Т. и К. Лонвик, "Протокол Secure Shell (SSH)
         Архитектура », RFC 4251, январь 2006 г.

   [22] Гровс, К., Панталео, М., Андерсон, Т., и Т. Тейлор, "Ворота
         Control Protocol Version 1 », RFC 3525, июнь 2003 г.

   [23] Баугер, М., Макгрю, Д., Наслунд, М., Каррара, Э. и К.
         Норрман, "Безопасный транспортный протокол в реальном времени (SRTP)",
         RFC 3711, март 2004 г.

   [24] Лаззаро, Дж., "Создание транспортного протокола в реальном времени (RTP) и
         Пакеты протокола управления RTP (RTCP) через ориентированные на соединение
         Транспорт », RFC 4571, июль 2006 г.Дорожка стандартов Lennox [Страница 15] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


Адрес автора

   Джонатан Леннокс
   Колумбийский университет, факультет компьютерных наук
   450 Компьютерные науки
   1214 Амстердам авеню, M.C. 0401
   Нью-Йорк, NY 10027
   НАС

   Электронная почта: [email protected]









































Дорожка стандартов Lennox [Страница 16] 

RFC 4572 Comedia over TLS в SDP июль 2006 г.


Полное заявление об авторских правах

   Авторское право (C) The Internet Society (2006).На этот документ распространяются права, лицензии и ограничения.
   содержится в BCP 78, и, за исключением случаев, указанных в нем, авторы
   сохраняют все свои права.

   Этот документ и содержащаяся в нем информация размещены на
   Принцип «КАК ЕСТЬ» и ПОСТАВЩИК, ОРГАНИЗАЦИЯ, ПРЕДСТАВЛЯЕМЫЕ ОН / ОНА
   ИЛИ СПОНСИРУЕТСЯ (ЕСЛИ ЕСТЬ) ИНТЕРНЕТ-ОБЩЕСТВОМ И ИНТЕРНЕТОМ
   ТЕХНИЧЕСКОЕ ОБРАЗОВАНИЕ ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ,
   ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯ ГАРАНТИЮ, ЧТО ИСПОЛЬЗОВАНИЕ
   ПРИСУТСТВУЮЩАЯ ИНФОРМАЦИЯ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ
   ГАРАНТИИ КОММЕРЧЕСКОЙ ЦЕННОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ.Интеллектуальная собственность

   IETF не занимает никакой позиции относительно действительности или объема любых
   Права интеллектуальной собственности или другие права, которые могут быть заявлены
   относятся к реализации или использованию технологии, описанной в
   этот документ или степень, в которой любая лицензия на такие права
   может быть, а может и нет; и не означает, что
   предпринял какие-либо независимые усилия для определения любых таких прав. Информация
   о процедурах в отношении прав в документах RFC может быть
   найдено в BCP 78 и BCP 79.Копии разглашения прав интеллектуальной собственности в секретариат IETF и
   гарантии предоставления лицензий или результат
   попытка получить генеральную лицензию или разрешение на использование
   такие права собственности разработчиками или пользователями этого
   спецификацию можно получить из он-лайн репозитория IETF IPR по адресу
   http://www.ietf.org/ipr.

   IETF приглашает любую заинтересованную сторону довести до ее сведения любые
   авторские права, патенты или заявки на патенты или другие проприетарные
   права, которые могут распространяться на технологии, которые могут потребоваться для реализации
   этот стандарт.Пожалуйста, направьте информацию в IETF по адресу
   [email protected]

Подтверждение

   Финансирование функции редактора RFC обеспечивается IETF.
   Административная поддержка деятельности (IASA).







Программа стандартов Lennox [Страница 17]

 

Разметка HTML, созданная rfcmarkup 1.129d, доступная по адресу https://tools.ietf.org/tools/rfcmarkup/

RFC 5763 — Основа для создания контекста безопасности безопасного транспортного протокола реального времени (SRTP) с использованием безопасности транспортного уровня дейтаграмм (DTLS)

[Документы] [txt | pdf] [draft-ietf-sip-…] [Tracker] [Diff1] [Diff2] [Errata]

ПРЕДЛАГАЕМЫЙ СТАНДАРТ
Errata Exist
Инженерная группа Интернета (IETF) Дж. Фишл
Запрос комментариев: 5763 Skype, Inc.
Категория: Стандарты Track H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
                                                             Э.Рескорла
                                                              RTFM, Inc.
                                                                Май 2010 г.


Платформа для создания безопасного транспортного протокола в реальном времени (SRTP)
    Контекст безопасности с использованием дейтаграммной безопасности транспортного уровня (DTLS)

Аннотация

   Этот документ определяет, как использовать протокол инициации сеанса.
   (SIP) для установления безопасного транспортного протокола в реальном времени (SRTP)
   контекст безопасности с использованием дейтаграммной безопасности транспортного уровня (DTLS)
   протокол.В нем описан механизм транспортировки отпечатка пальца.
   атрибут в протоколе описания сеанса (SDP), который определяет
   ключ, который будет представлен во время рукопожатия DTLS. Ключ
   обмен перемещается по пути мультимедиа в отличие от сигнализации
   путь. Механизм SIP Identity может использоваться для защиты
   целостность атрибута отпечатка пальца от модификации
   промежуточные прокси.

Статус этой памятки

   Это документ Internet Standards Track.

   Этот документ является продуктом Инженерной группы Интернета.
   (IETF).Он представляет собой консенсус сообщества IETF. Оно имеет
   получил публичное рецензирование и был одобрен к публикации
   Инженерная группа управления Интернетом (IESG). Дополнительная информация о
   Интернет-стандарты доступны в разделе 2 RFC 5741.

   Информация о текущем статусе этого документа, исправлениях,
   и как оставить отзыв о нем можно узнать на
   http://www.rfc-editor.org/info/rfc5763.













Fischl, et al. Стандарты Track [Страница 1] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


Уведомление об авторских правах

   Авторское право (c) 2010 IETF Trust и лица, указанные как
   авторы документа.Все права защищены.

   Этот документ регулируется BCP 78 и Правовой нормой IETF Trust.
   Положения, касающиеся документов IETF
   (http://trustee.ietf.org/license-info) действует на дату
   публикация этого документа. Просмотрите эти документы
   внимательно, поскольку они уважительно описывают ваши права и ограничения
   к этому документу. Компоненты кода, извлеченные из этого документа, должны
   включить упрощенный текст лицензии BSD, как описано в разделе 4.e
   Правовые положения Trust и предоставляются без гарантии, как
   описана в упрощенной лицензии BSD.Этот документ может содержать материалы из документов IETF или IETF.
   Материалы опубликованы или станут общедоступными до ноября
   10, 2008. Лица, контролирующие авторские права на некоторые из этих
   материал, возможно, не давал IETF Trust право разрешать
   модификации такого материала вне процесса стандартизации IETF.
   Без получения соответствующей лицензии от лица (лиц), контролирующего
   авторские права на такие материалы, этот документ не может быть изменен
   вне Процесса стандартов IETF, и производные от него разработки могут
   не создаваться вне процесса стандартов IETF, кроме как для форматирования
   его для публикации как RFC или для перевода на другие языки
   чем английский.Содержание

   1. Введение ............................................... ..... 4
   2. Обзор ............................................... ......... 5
   3. Мотивация ............................................... ....... 7
   4. Терминология ............................................... ...... 8
   5. Создание безопасного канала ................................... 8
   6. Прочие соображения ................................... 10
      6.1. Анонимные звонки ........................................... 10
      6.2. Ранние СМИ ............................................... 11
      6.3. Вилка ................................................. ..11
      6.4. Звонки с отложенным предложением ....................................... 11
      6.5. Множественные ассоциации ..................................... 11
      6.6. Модификация сеанса ...................................... 12
      6.7. Взаимодействие мидлбокса ..................................... 12
           6.7.1. ICE взаимодействие.................................... 12
           6.7.2. Блокировка без ДВС ....................... 13
      6.8. Смена ключей ................................................. .13
      6.9. Серверы конференций и контексты Shared Encryptions ........ 13
      6.10. Медиа через SRTP .......................................... 14
      6.11. Шифрование Best Effort ................................... 14



Fischl, et al. Стандарты Track [Страница 2] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   7.Пример потока сообщений ........................................... 14
      7.1. Базовый поток сообщений с ранними носителями и идентификатором SIP ... 14
      7.2. Базовый поток сообщений с подключенной идентификацией (RFC 4916) ..... 19
      7.3. Основной поток сообщений с проверкой STUN на случай NAT ........... 23
   8. Соображения безопасности ........................................ 25
      8.1. Идентификационные данные респондента ........................................ 25
      8.2. ГИПС ................................................. .....26
      8.3. S / MIME ............................................... ..... 26
      8.4. Непрерывность аутентификации .............................. 26
      8.5. Короткая строка аутентификации ............................... 27
      8.6. Пределы утверждения личности ............................. 27
      8.7. Сторонние сертификаты .................................. 29
      8.8. Совершенная прямая секретность ................................... 29
   9. Благодарности ................................................ 29
   10. Ссылки ............................................... ..... 30
      10.1. Нормативные ссылки ..................................... 30
      10.2. Информационные ссылки ................................... 31
   Приложение A. Анализ требований ................................ 33
      А.1. Форкинг и ретаргетинг (R-FORK-RETARGET,
            R-BEST-SECURE, R-DISTINCT) ............................... 33
      А.2. Отчетливые криптографические контексты (R-DISTINCT) ............. 33
      А.3. Повторное использование контекста безопасности (R-REUSE) .................. 33
      А.4. Обрезка (R-AVOID-CLIPPING) .............................. 33
      А.5. Пассивные атаки на медиа-тракт (R-PASS-MEDIA) ......... 33
      А.6. Пассивные атаки на сигнальном тракте (R-PASS-SIG) ....... 34
      А.7. (R-SIG-MEDIA, R-ACT-ACT) ................................. 34
      А.8. Привязка к идентификаторам (R-ID-BINDING) .................... 34
      А.9. Совершенная прямая секретность (R-PFS) .......................... 34
      А.10. Согласование алгоритма (R-COMPUTE) ........................ 35
      А.11. Проверка действительности RTP (R-RTP-VALID) ......................... 35
      А.12. Сторонние сертификаты (R-CERTS, R-EXISTING) ........... 35
      А.13. FIPS 140-2 (R-FIPS) ...................................... 35
      А.14. Связь между обменом ключами и сигнализацией SIP
            (R-ASSOC) ............................................. ... 35
      А.15. Уязвимость, связанная с отказом в обслуживании (R-DOS) .................. 35
      А.16. Крипто-гибкость (R-AGILITY) ............................... 35
      А.17. Защита от понижения (R-DOWNGRADE) ..................... 36
      А.18. Согласование безопасности мультимедиа (R-NEGOTIATE) ................. 36
      А.19. Независимость протокола сигнализации (R-OTHER-SIGNALING) ...... 36
      А.20. Медиа-запись (R-RECORDING) ............................ 36
      А.21. Взаимодействие с посредниками (R-TRANSCODER) .......... 36
      А.22. Терминация шлюза PSTN (R-PSTN) ........................ 36
      А.23. R-ALLOW-RTP ............................................. 0,36
      А.24. R-HERFP ............................................... ... 37







Fischl, et al. Стандарты Track [Страница 3] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


1. Введение

   Протокол инициации сеанса (SIP) [RFC3261] и сеанс
   Протокол описания (SDP) [RFC4566] используется для настройки мультимедиа.
   сеансы или звонки.SDP также используется для настройки TCP [RFC4145] и
   дополнительно TCP / TLS-соединения для использования с медиа-сессиями
   [RFC4572]. Используется транспортный протокол реального времени (RTP) [RFC3550].
   для передачи мультимедиа в реальном времени поверх UDP и TCP [RFC4571].
   Дейтаграмма TLS [RFC4347] была введена, чтобы позволить функциональности TLS
   применяться к транспортным протоколам дейтаграмм, таким как UDP и DCCP.
   В этом документе приведены инструкции по установке SRTP [RFC3711]
   безопасность через UDP с использованием расширения DTLS (см. [RFC5764]).Цель этой работы - предоставить ключевую технику переговоров, которая
   позволяет зашифрованную связь между устройствами без предварительного
   отношения. Это также не требует, чтобы устройства доверяли каждому
   элемент сигнализации вызова, который участвовал в маршрутизации или настройке сеанса.
   Такой подход не требует дополнительных усилий со стороны конечных пользователей и делает
   не требовать развертывания сертификатов, подписанных хорошо
   известный центр сертификации для всех устройств.

   Медиа транспортируются через сеанс DTLS с взаимной аутентификацией.
   где у обеих сторон есть сертификаты.Очень важно отметить
   что сертификаты используются исключительно как носитель для общественности
   ключи сверстников. Это необходимо, потому что DTLS не имеет
   режим для ношения голых ключей, но это чисто вопрос форматирования.
   Сертификаты могут быть самоподписанными и полностью самогенерируемыми.
   Все основные стеки TLS могут создавать такие
   сертификаты по запросу. Однако сторонние сертификаты МОГУТ также
   использоваться, если они есть у партнеров (что снижает потребность в доверии
   посредники).Отпечатки сертификатов отправляются в SDP через
   SIP как часть обмена предложениями / ответами.

   Механизм отпечатка пальца позволяет одной стороне соединения проверить
   что сертификат, представленный в рукопожатии DTLS, соответствует
   сертификат, используемый стороной в сигнализации. Однако это
   требует некоторой защиты целостности сигнализации. S / MIME
   подписи, как описано в RFC 3261, или SIP Identity, как описано
   в [RFC4474], обеспечивают высочайший уровень безопасности, поскольку они
   не подвержен модификации злонамеренными посредниками.Однако даже поэтапная безопасность, такая как SIPS, предлагает
   некоторая защита от модификации злоумышленниками, которые не находятся в
   управление элементами путевой сигнализации. Потому что только DTLS-SRTP
   требует целостности сообщения, а не конфиденциальности для сигнализации,
   количество элементов, которые должны иметь учетные данные и которым можно доверять, равно
   значительно уменьшено. В частности, если используется RFC 4474, только
   Служба аутентификации должна иметь сертификат и быть доверенным.
   Промежуточные элементы не могут незаметно изменить сообщение и



Fischl, et al.Стандарты Track [Страница 4] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   следовательно, не может организовать атаку "человек посередине" (MITM). По
   сравнение, потому что SDESCRIPTIONS [RFC4568] требует конфиденциальности
   для сигнализации все промежуточные элементы должны быть доверенными.

   Этот подход отличается от предыдущих попыток защитить медиа-трафик.
   где протокол аутентификации и обмена ключами (например, Multimedia
   Internet KEYing (MIKEY) [RFC3830]) встроен в сигнализацию.
   обмен сообщениями.С DTLS-SRTP, устанавливая защиту
   медиа-трафик между конечными точками осуществляется конечными медиа-точками
   только с криптографической привязкой медиа-ключа к SIP / SDP
   общение. Это позволяет использовать RTP и SIP обычным образом.
   когда нет зашифрованного носителя.

   В SIP обычно вызывающий отправляет предложение, а вызываемый может
   впоследствии отправить односторонний носитель обратно вызывающему абоненту перед SIP
   ответ получает звонящий. Подход в этом
   спецификация, где согласование медиа-ключа отделено от
   Сигнализация SIP, позволяет установить ранний носитель до SIP
   ответ получен при сохранении важного охранного свойства
   разрешить отправителю СМИ выбрать некоторые ключевые материалы
   для СМИ.Это также позволяет изменять сеансы мультимедиа,
   с измененным ключом или иным образом измененным после первоначальной сигнализации SIP
   без дополнительной сигнализации SIP.

   Проектные решения, влияющие на применимость этого
   спецификации обсуждаются в разделе 3.

2. Обзор

   Конечные точки, желающие установить сеанс мультимедиа RTP, делают это путем обмена
   предложения и ответы в сообщениях SDP по SIP. В типичном случае использования
   две конечные точки будут согласовывать передачу аудиоданных через RTP, используя
   протокол UDP.На рисунке 1 показан типичный обмен сообщениями в трапеции SIP.
















Fischl, et al. Стандарты Track [Страница 5] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


                 + ----------- + + ----------- +
                 | SIP | SIP / SDP | SIP |
         + ------> | Прокси | -----------> | Прокси | ------- +
         | | Сервер X | (+ finger- | Сервер Y | |
         | + ----------- + печать, + ----------- + |
         | + авт.ид.) |
         | SIP / SDP SIP / SDP |
         | (+ отпечаток пальца) (+ отпечаток пальца, |
         | + auth.id.) |
         | |
         | v
     + ----------- + Датаграмма TLS + ----------- +
     | SIP | <- + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + -> | SIP |
     | Пользовательский агент | Медиа | Пользовательский агент |
     | Алиса @ X | <=================================> | Боб @ Y |
     + ----------- + + ----------- +

     Легенда:
     ------>: Сигнализация трафика
     <- + - + ->: трафик управления ключами
     <=====>: Трафик данных

                 Рисунок 1: Использование DTLS в трапеции SIP

   Представьте, что Алиса хочет установить зашифрованный аудиосеанс с
   Боб.И Боб, и Алиса могли использовать аутентификацию на основе открытого ключа в
   чтобы установить канал с защитой конфиденциальности с помощью DTLS.

   Поскольку обеспечение взаимной аутентификации между двумя произвольными конечными точками
   в Интернете использование криптографии на основе открытых ключей имеет тенденцию
   проблематично, мы рассматриваем более удобные для развертывания альтернативы. Этот
   документ использует один подход, а несколько других обсуждаются в
   Раздел 8.

   Алиса отправляет Бобу предложение SDP по SIP. Если Алиса использует только самообслуживание
   подписанные сертификаты для связи с Бобом, отпечаток пальца
   включены в обмен предложениями / ответами SDP.Этот отпечаток пальца связывает
   обмен ключами DTLS в медиаплоскости к плоскости сигнализации.

   Один только отпечаток пальца защищает от активных атак на СМИ
   но не активные атаки на сигнализацию. Во избежание активного
   атаки на сигнализацию "Усовершенствования для аутентифицированной идентификации
   Управление в протоколе инициации сеанса (SIP) »[RFC4474] может быть
   используемый. Когда Боб получает предложение, одноранговые узлы устанавливают некоторое число
   соединений DTLS (в зависимости от количества медиа-сессий) с
   взаимная аутентификация DTLS (т.е.е., обе стороны предоставляют сертификаты).
   На этом этапе Боб может проверить, что учетные данные Алисы, предложенные в TLS
   сопоставьте отпечаток пальца в предложении SDP, и Боб может начать отправку



Fischl, et al. Стандарты Track [Страница 6] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   СМИ Алисе. Как только Боб принимает предложение Алисы и отправляет SDP
   ответ Алисе, Алиса может начать отправлять Бобу конфиденциальные данные
   над соответствующими потоками.Алиса и Боб проверит, что
   отпечатки пальцев от сертификатов, полученных при рукопожатиях DTLS
   совпадают с отпечатками пальцев, полученными в SDP сигнализации SIP.
   Это обеспечивает свойство безопасности, которое Алиса знает, что медиа
   трафик идет к Бобу и наоборот без необходимости
   глобальные сертификаты инфраструктуры открытых ключей (PKI) для Алисы и
   Боб. (Подробный анализ безопасности см. В разделе 8.)

3. Мотивация

   Хотя в этой области уже есть предварительные работы (например,г., Безопасность
   Описания SDP [RFC4568], расширений управления ключами [RFC4567]
   в сочетании с MIKEY [RFC3830] для аутентификации и обмена ключами),
   эта спецификация мотивирована следующим образом:

   o TLS будет использоваться для обеспечения безопасности носителей с установлением соединения.
      Дизайн TLS хорошо известен, а его реализации широко распространены.
      имеется в наличии.

   o Этот подход имеет дело с разветвлением и ранними носителями без необходимости
      поддержка предварительного подтверждения ответа (PRACK) [RFC3262]
      при сохранении важного свойства безопасности, позволяющего
      предлагающий выбрать ключевой материал для шифрования носителя.o Установление защиты для тракта носителя
      также предоставляется по пути передачи данных, а не по сигнальным
      путь. Во многих сценариях развертывания сигнализация и медиа
      трафик перемещается по другому пути в сети.

   o Когда используется RFC 4474, это решение работает, даже если SIP
      прокси-серверы нижестоящей службы аутентификации не являются доверенными.
      Нет необходимости раскрывать ключи в сигнализации SIP или в SDP
      обмен сообщениями, как это сделано в SDESCRIPTIONS [RFC4568].Ретаргетинг диалогового запроса (изменение значения
      Request-URI), пользовательский агент (UA), который его получает (пользовательский агент
      Server, UAS) может иметь идентификатор, отличный от идентификатора в поле Кому.
      поле заголовка. Когда используется RFC 4916, можно
      предоставить свою идентичность одноранговому UA посредством запроса в
      обратном направлении, и чтобы это удостоверение было подписано
      Служба аутентификации.

   o В этом методе коллизии источника синхронизации (SSRC) не
      приведет к любой дополнительной сигнализации SIP.Fischl, et al. Стандарты Track [Страница 7] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   o Многие конечные точки SIP уже реализуют TLS. Изменения в существующих
      Использование SIP и RTP минимально, даже если DTLS-SRTP [RFC5764]
      используемый.

4. Терминология

   Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ»,
   «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом
   документ следует интерпретировать, как описано в [RFC2119].DTLS / TLS использует термин «сеанс» для обозначения долговременного набора
   ключевой материал, который охватывает ассоциации. В этом документе
   в соответствии с использованием SIP / SDP, мы используем его для обозначения мультимедийного
   сеанс и используйте термин «сеанс TLS» для обозначения конструкции TLS.
   Мы используем термин «ассоциация» для обозначения конкретного шифра DTLS.
   набор и набор ключевых материалов, связанный с одним хостом /
   портовый квартет. Тот же сеанс DTLS / TLS можно использовать для установления
   ключевой материал для нескольких ассоциаций.Для согласованности с
   другое использование SIP / SDP, мы используем термин "соединение", когда
   упоминается мультимедийный поток, который не является конкретно DTLS / TLS.

   В этом документе термин «Взаимный DTLS» означает, что оба DTLS
   клиент и сервер представляют сертификаты, даже если один или оба
   сертификаты самозаверяющие.

5. Создание безопасного канала

   Две конечные точки в обмене представляют свои идентификаторы как часть
   процедура установления связи DTLS с использованием сертификатов. В этом документе используется
   сертификаты в том же стиле, как описано в разделе «Ориентированный на подключение
   Транспортировка мультимедиа по протоколу безопасности транспортного уровня (TLS) в
   протокол описания сеанса (SDP) »[RFC4572].Если используются самозаверяющие сертификаты, содержимое
   Атрибут subjectAltName внутри сертификата МОЖЕТ использовать унифицированный
   идентификатор ресурса (URI) пользователя. Это полезно для отладки
   только для целей и не требуется для привязки сертификата к одному из
   конечные точки связи. Целостность сертификата
   обеспечивается атрибутом отпечатка пальца в SDP. В
   subjectAltName не является важным компонентом сертификата
   проверка.

   Создание пар открытого и закрытого ключей относительно дорого.Конечным точкам не требуется создавать сертификаты для каждого сеанса.

   Модель предложения / ответа, определенная в [RFC3264], используется протоколами.
   например, протокол инициации сеанса (SIP) [RFC3261] для настройки
   мультимедийные сеансы. В дополнение к обычному содержимому SDP



Fischl, et al. Стандарты Track [Страница 8] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   [RFC4566] сообщение, описание каждого носителя (строка "m =" и связанные
   параметры) также будет содержать несколько атрибутов, как указано в
   [RFC5764], [RFC4145] и [RFC4572].Когда конечная точка желает установить безопасный медиа-сеанс с другим
   конечная точка, он отправляет предложение в сообщении SIP другой конечной точке.
   Это предложение включает в себя как часть полезной нагрузки SDP отпечаток пальца
   сертификат, который конечная точка хочет использовать. Конечная точка ДОЛЖНА
   отправить SIP-сообщение, содержащее предложение, на SIP-прокси оферента
   по каналу с защитой целостности. Прокси-сервер ДОЛЖЕН добавить
   Поле заголовка удостоверения в соответствии с процедурами, изложенными в
   [RFC4474].SIP-сообщение, содержащее предложение, ДОЛЖНО быть отправлено по адресу
   прокси-сервер SIP оферента по каналу с защитой целостности. когда
   удаленная конечная точка получает сообщение SIP, она может проверить личность
   отправителя, используя поле заголовка Identity. Поскольку личность
   поле заголовка - это цифровая подпись в нескольких полях заголовка SIP,
   помимо тела SIP-сообщения, получатель также может быть
   уверен, что сообщение не было подделано после цифрового
   подпись была применена и добавлена ​​к SIP-сообщению.Дальняя конечная точка (ответчик) теперь может установить связь DTLS с
   оферент. В качестве альтернативы он может указать в своем ответе, что
   оферент должен инициировать ассоциацию TLS. В любом случае взаимное
   Будет использоваться аутентификация на основе сертификата DTLS. После завершения
   рукопожатие DTLS, информация об аутентифицированных идентификаторах,
   включая сертификаты, становятся доступными для конечной точки
   применение. Затем ответчик может проверить, что
   сертификат, используемый для аутентификации в рукопожатии DTLS, может быть
   связанный с отпечатком сертификата, содержащимся в предложении в
   SDP.На этом этапе ответчик может указать конечному пользователю
   что средства массовой информации защищены. Оферент может принять только предварительно
   сертификат ответчика, поскольку он может еще не иметь
   отпечаток сертификата.

   Когда отвечающий принимает предложение, он дает ответ на
   оферент, содержащий отпечаток сертификата ответчика. В
   на этом этапе предлагающий может принять или отклонить сертификат партнера.
   и предлагающий может указать конечному пользователю, что носитель
   обеспечен.Обратите внимание, что вся проверка подлинности и обмен ключами для защиты
   медиа-трафик обрабатывается в медиа-тракте через DTLS. В
   сигнальный путь используется только для проверки сертификата одноранговых узлов
   отпечатки пальцев.







Fischl, et al. Стандарты Track [Страница 9] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   Предложение и ответ ДОЛЖНЫ соответствовать следующим требованиям.

   o Конечная точка ДОЛЖНА использовать атрибут установки, определенный в [RFC4145].Конечная точка, предлагающая оферент, ДОЛЖНА использовать атрибут настройки
      значение настройки: actpass и будьте готовы получить client_hello
      прежде, чем он получит ответ. Отвечающий ДОЛЖЕН использовать либо
      значение атрибута setup для setup: active или setup: passive. Обратите внимание, что
      если отвечающий использует setup: passive, то рукопожатие DTLS будет
      не начинать, пока не будет получен ответчик, что добавляет дополнительные
      задержка. setup: active разрешает ответ и рукопожатие DTLS для
      происходят параллельно.Таким образом, РЕКОМЕНДУЕТСЯ setup: active. какой бы ни
      участник активен ДОЛЖЕН инициировать рукопожатие DTLS, отправив
      ClientHello по каждому потоку (квартет хост / порт).

   o Конечная точка НЕ ​​ДОЛЖНА использовать атрибут соединения, определенный в
      [RFC4145].

   o Конечная точка ДОЛЖНА использовать атрибут отпечатка сертификата как
      указано в [RFC4572].

   o Сертификат, представленный во время рукопожатия DTLS, ДОЛЖЕН соответствовать
      обмен отпечатками пальцев через сигнальный путь в SDP. В
      Свойства безопасности этого механизма описаны в разделе 8.o Если отпечаток пальца не соответствует хешированному сертификату, то
      конечная точка ДОЛЖНА немедленно прервать медиа-сеанс. Обратите внимание, что
      допустимо подождать, пока отпечаток пальца другой стороны
      был получен до установления соединения; однако это
      может иметь нежелательные эффекты задержки.

6. Прочие соображения

6.1. Анонимные звонки

   Использование DTLS-SRTP не обеспечивает анонимного вызова; однако это
   тоже не мешает. Однако, если не соблюдать осторожность, когда
   функции анонимного вызова, например, описанные в [RFC3325] или
   [RFC5767], DTLS-SRTP может позволить деанонимизировать в противном случае
   анонимный звонок.При выполнении анонимных вызовов следующие
   СЛЕДУЕТ использовать процедуры для предотвращения деанонимизации.

   При выполнении анонимных вызовов СЛЕДУЕТ использовать новый самозаверяющий сертификат.
   используется для каждого звонка, так что звонки не могут быть сопоставлены
   от того же абонента. В ситуациях, когда некоторая степень корреляции
   приемлемо, один и тот же сертификат ДОЛЖЕН использоваться для нескольких
   звонки, чтобы обеспечить непрерывность аутентификации; видеть
   Раздел 8.4.




Fischl, et al. Стандарты Track [Страница 10] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   Кроме того, обратите внимание, что в сетях, которые развертывают [RFC3325], RFC 3325
   требует, чтобы значение поля заголовка Privacy определено в [RFC3323]
   должен быть установлен в "id".Используется вместе с протоколом SIP.
   механизм идентификации, чтобы гарантировать, что личность пользователя не
   утверждается при включении анонимных вызовов. Кроме того, содержание
   атрибут subjectAltName внутри сертификата НЕ ДОЛЖЕН содержать
   информация, которая позволяет либо сопоставить, либо идентифицировать
   пользователь, желающий сделать анонимный звонок. Обратите внимание, что следующие
   этой рекомендации недостаточно для обеспечения анонимности.

6.2. Ранние СМИ

   Если предложение получено конечной точкой, которая хочет предоставить
   media, он ДОЛЖЕН принимать настройку: активную роль и может немедленно
   установить связь DTLS с другой конечной точкой и начать
   отправка СМИ.Настройка: пассивная конечная точка, возможно, еще не прошла проверку
   отпечаток сертификата активной конечной точки. Охрана
   аспекты работы со СМИ в этой ситуации обсуждаются в
   Раздел 8.

6.3. Разветвление

   В SIP запрос может быть передан нескольким конечным точкам.
   Каждый разветвленный запрос может давать разные ответы. При условии, что
   запрашивающий предоставил предложение, каждый из ответивших предоставит
   единственный ответ. Каждый отвечающий сформирует DTLS-ассоциацию с
   оферент.Затем оферент может безопасно сопоставить ответ SDP.
   полученный в сообщении SIP путем сравнения отпечатка пальца в
   ответ на хешированный сертификат для каждой ассоциации DTLS.

6.4. Звонки с отложенным предложением

   Конечная точка может отправить запрос SIP INVITE без предложения. когда
   это происходит, получатель (и) ПРИГЛАШЕНИЯ предоставит предложение в
   ответ, и автор предоставит ответ в
   последующий запрос ACK или запрос PRACK [RFC3262], если оба
   конечные точки поддерживают надежные предварительные ответы.В любом случае
   активная конечная точка все еще устанавливает связь DTLS с
   пассивная конечная точка, согласованная при обмене предложением / ответом.

6.5. Множественные ассоциации

   Когда существует несколько потоков (например, несколько потоков мультимедиа, не
   мультиплексированные RTP и RTCP и т. д.) активная сторона МОЖЕТ выполнять DTLS
   рукопожатия в любом порядке. Приложение B [RFC5764] содержит некоторые
   руководство по производительности параллельного установления связи DTLS. Обратите внимание, что
   если ответчик оказывается активным, он может только инициировать рукопожатие
   на некотором подмножестве потенциальных потоков (например,g., если аудио и видео



Fischl, et al. Стандарты Track [Страница 11] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   предложил, но он только хочет сделать аудио). Если оферент заканчивается
   будучи активным, полный ответ будет получен до того, как предлагающий
   начинает рукопожатие.

6.6. Модификация сеанса

   После получения ответа оференту любая конечная точка МОЖЕТ
   запросить модификацию сеанса, которая МОЖЕТ включать обновленное предложение.Это изменение сеанса может быть передано либо в ПРИГЛАШЕНИИ, либо в
   ОБНОВЛЕНИЕ запрос. Одноранговые узлы могут повторно использовать существующие ассоциации, если
   они совместимы (т. е. имеют одинаковые отпечатки пальцев и
   транспортных параметров), либо установить новый по тем же
   правила предназначены для первоначального обмена, разрушая существующие
   ассоциация, как только обмен предложения / ответа завершен. Запись
   что если активный / пассивный статус конечных точек изменится, новый
   соединение ДОЛЖНО быть установлено.6.7. Взаимодействие с промежуточным ящиком

   Между DTLS-SRTP существует ряд потенциально плохих взаимодействий.
   и промежуточные ящики, как описано в [MMUSIC-MEDIA], который также обеспечивает
   рекомендации по предотвращению таких проблем.

6.7.1. ICE взаимодействие

   Установление интерактивного подключения (ICE), как указано в
   [RFC5245], предоставляет методологию, позволяющую участникам
   мультимедийные сеансы для проверки взаимного подключения. Когда ICE
   используются, проверки подключения ICE выполняются перед DTLS
   рукопожатие начинается.Обратите внимание, что если используется агрессивный режим номинации,
   несколько пар кандидатов могут быть помечены как действительные до окончательного ICE
   сходится к единственной паре кандидатов. Реализации ДОЛЖНЫ обрабатывать все
   Пары кандидатов ICE, связанные с одним компонентом как часть
   та же ассоциация DTLS. Таким образом, будет только одно рукопожатие DTLS.
   даже если есть несколько допустимых пар кандидатов. Обратите внимание, что это может
   означает корректировку IP-адресов конечных точек, если выбранный кандидат
   парные сдвиги, как если бы пакеты DTLS были обычным носителем
   поток.Обратите внимание, что простой обход протокола UDP через NAT (STUN)
   пакеты отправляются напрямую через UDP, а не через DTLS. [RFC5764]
   описывает, как демультиплексировать пакеты STUN из пакетов DTLS и SRTP.
   пакеты.








Fischl, et al. Стандарты Track [Страница 12] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


6.7.2. Управление фиксацией без ДВС

   Если ICE не используется, есть вероятность плохого
   взаимодействие с пограничными контроллерами сеансов (SBC) посредством «фиксации», как
   описано в [MMUSIC-MEDIA].Чтобы избежать этой проблемы, если ICE
   не используется, и рукопожатие DTLS не завершено
   получая SDP другой стороны, тогда пассивная сторона ДОЛЖНА выполнить
   одиночная неаутентифицированная проверка подключения STUN [RFC5389] для
   откройте соответствующее отверстие. Все реализации ДОЛЖНЫ быть
   готовы ответить на этот запрос во время периода рукопожатия, даже если
   они иначе не делают ICE. Однако активная сторона ДОЛЖНА продолжить
   с подтверждением DTLS в зависимости от ситуации, даже если такая проверка STUN не выполняется.
   получен, а пассивный НЕ ДОЛЖЕН ждать ответа STUN до
   отправив свой ServerHello.6.8. Смена ключей

   Как и в случае с TLS, конечные точки DTLS могут в любой момент изменить ключ, повторив DTLS.
   рукопожатие. Пока происходит изменение ключа, конечные точки продолжают
   используйте ранее установленный ключевой материал для использования с DTLS.
   Как только новые ключи сеанса установлены, сеанс может переключиться на
   используя их и откажитесь от старых ключей. Это гарантирует, что задержка
   не вводится в процессе смены ключей.

   Дальнейшие соображения относительно смены ключей в случае безопасности SRTP
   контекст устанавливается с помощью DTLS, можно найти в Разделе 3.7 из
   [RFC5764].

6.9. Серверы конференций и контексты общего шифрования

   Было предложено, чтобы серверы конференций могли использовать тот же
   контекст шифрования для всех участников конференции. В
   Преимущество этого подхода в том, что серверу конференции требуется только
   чтобы зашифровать вывод для всех динамиков, а не один раз на
   участник.

   Такой подход с общим контекстом шифрования невозможен в рамках этого
   спецификация, потому что каждое рукопожатие DTLS устанавливает новые ключи, которые
   не полностью контролируются ни одной из сторон.Однако это
   утверждал, что усилия по шифрованию каждого пакета RTP невелики по сравнению с
   к другим задачам, выполняемым сервером конференции, таким как
   кодек обработки.

   Будущие расширения, такие как [SRTP-EKT] или [KEY-TRANSPORT], могут быть
   используется для обеспечения этой функциональности совместно с механизмами
   описано в этой спецификации.





Fischl, et al. Стандарты Track [Страница 13] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


6.10. Медиа через SRTP

   Поскольку протокол передачи данных DTLS является универсальным, он менее эффективен.
   оптимизирован для использования с RTP, чем SRTP [RFC3711], который был
   специально настроен для этой цели. DTLS-SRTP [RFC5764] был
   определен для обеспечения согласования транспорта SRTP с использованием DTLS
   соединение, что позволяет получить преимущества производительности SRTP с
   легкое управление ключами DTLS. Возможность повторного использования существующего SRTP
   программные и аппаратные реализации могут в некоторых средах
   предоставить еще одну важную мотивацию для использования DTLS-SRTP вместо
   RTP через DTLS.Реализации этой спецификации ДОЛЖНЫ поддерживать
   DTLS-SRTP [RFC5764].

6.11. Лучшее шифрование

   [RFC5479] описывает требование наилучшего шифрования, если
   Используется SRTP, и обе конечные точки поддерживают его и согласование ключей
   успешно, в противном случае используется RTP.

   [MMUSIC-SDP] описывает механизм, который может сигнализировать как RTP, так и SRTP.
   как альтернатива. Это позволяет оференту выразить предпочтение
   для SRTP, но RTP используется по умолчанию и будет понят конечным точкам
   которые не понимают SRTP или этот механизм обмена ключами.Реализации этого документа ДОЛЖНЫ поддерживать [MMUSIC-SDP].

7. Пример потока сообщений

   Перед установкой сеанса и Алиса, и Боб генерируют самообслуживание.
   подписанные сертификаты, которые используются для одного сеанса или более
   вероятно, используется повторно для нескольких сеансов. В этом примере Алиса вызывает
   Боб. В этом примере мы предполагаем, что Алиса и Боб имеют один и тот же
   прокси.

7.1. Базовый поток сообщений с ранними носителями и идентификатором SIP

   В этом примере показаны потоки сообщений SIP, в которых Алиса действует как
   пассивная конечная точка, и Боб действует как активная конечная точка; это означает, что как
   как только Боб получит ПРИГЛАШЕНИЕ от Алисы, с указанием DTLS в
   строка "m =" предложения, Боб начнет согласование DTLS
   связь с Алисой для потоков RTP и RTCP.Ранние СМИ
   (RTP и RTCP) начинает передаваться от Боба к Алисе, как только Боб отправляет
   сообщение о завершении DTLS Алисе. Двунаправленная среда (RTP и
   RTCP) может передаваться после того, как Алиса получит ответ SIP 200 и один раз
   Алиса отправила сообщение о завершении DTLS.







Fischl, et al. Стандарты Track [Страница 14] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   Сигнализация SIP от Алисы к ее прокси-серверу передается по TLS в
   обеспечить защищенный канал между Алисой и ее личностью
   служба.Транспорт между прокси тоже надо как-то защищать,
   особенно, если SIP Identity не используется.

   Алиса Прокси Боб
     | (1) ПРИГЛАСИТЬ | |
     | ----------------> | |
     | | (2) ПРИГЛАСИТЬ |
     | | -----------------> |
     | | (3) привет |
     | <----------------------------------- |
     | (4) привет | |
     | -----------------------------------> |
     | | (5) закончено |
     | <----------------------------------- |
     | | (6) СМИ |
     | <----------------------------------- |
     | (7) закончено | |
     | -----------------------------------> |
     | | (8) 200 ОК |
     | <------------------ |
     | (9) 200 ОК | |
     | <---------------- | |
     | | (10) СМИ |
     | <----------------------------------> |
     | (11) ACK | |
     | -----------------------------------> |

   Сообщение (1): ПРИГЛАСИТЬ Алису -> Прокси

      Это показывает первоначальное ПРИГЛАШЕНИЕ от Алисы к Бобу, перенесенное через
      Транспортный протокол TLS для обеспечения канала с защитой целостности
      между Алисой и ее прокси, который действует как служба идентификации Алисы.Алиса запросила роль активной или пассивной конечной точки
      указав a = setup: actpass в SDP. Боб предпочитает действовать как
      Клиент DTLS и инициирует сеанс. Также обратите внимание, что там
      - это атрибут отпечатка пальца в SDP. Это вычислено из
      Самоподписанный сертификат Алисы.

      Это предложение включает строку "m =" по умолчанию, предлагающую RTP в случае, если
      ответчик не поддерживает SRTP. Однако потенциал
      предпочтительна конфигурация с использованием транспорта SRTP.Видеть
      [MMUSIC-SDP] для получения дополнительных сведений о возможностях SDP.
      Переговоры.






Fischl, et al. Стандарты Track [Страница 15] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   ПРИГЛАСИТЬ sip: [email protected] SIP / 2.0
   Кому: 
   От: "Алиса" ; tag = 843c7b0b
   Через: SIP / 2.0 / TLS ua1.example.com; branch = z9hG4bK-0e53sadfkasldkfj
   Контакты: 
   Call-ID: 6076913b1c39c212 @ REVMTEpG
   CSeq: 1 ПРИГЛАШАТЬ
   Разрешить: ПРИГЛАШЕНИЕ, ПОДТВЕРЖДЕНИЕ, ОТМЕНА, ОПЦИИ, ПОКА, ОБНОВЛЕНИЕ
   Максимальное количество нападающих: 70
   Тип содержимого: приложение / sdp
   Длина содержимого: xxxx
   Поддерживается: от-изменить

   v = 0
   o = - 1181923068 1181923196 В IP4 ua1.example.com
   s = example1
   c = IN IP4 ua1.example.com
   a = настройка: actpass
   a = отпечаток пальца: SHA-1 \
     4A: AD: B9: B1: 3F: 82: 18: 3B: 54: 02: 12: DF: 3E: 5D: 49: 6B: 19: E5: 7C: AB
   т = 0 0
   m = аудио 6056 RTP / AVP 0
   a = sendrecv
   a = tcap: 1 UDP / TLS / RTP / SAVP RTP / AVP
   а = pcfg: 1 t = 1

   Сообщение (2): ПРИГЛАСИТЬ Прокси -> Боб

      Это показывает, что ПРИГЛАШЕНИЕ передается Бобу от Алисы (и Боба).
      прокси.Обратите внимание, что прокси Алисы вставил идентификатор и
      Заголовок Identity-Info. В этом примере показан только один элемент для
      оба прокси в целях упрощения. Боб проверяет
      удостоверение личности, предоставленное с INVITE.


















Fischl, et al. Стандарты Track [Страница 16] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   ПРИГЛАСИТЬ sip: [email protected] SIP / 2.0
   Кому: 
   От: "Алиса" ; tag = 843c7b0b
   Через: SIP / 2.0 / TLS proxy.example.com; branch = z9hG4bK-0e53sadfkasldk
   Через: SIP / 2.0 / TLS ua1.example.com; branch = z9hG4bK-0e53sadfkasldkfj
   Запись-Маршрут: 
   Контакты: 
   Call-ID: 6076913b1c39c212 @ REVMTEpG
   CSeq: 1 ПРИГЛАШАТЬ
   Разрешить: ПРИГЛАШЕНИЕ, ПОДТВЕРЖДЕНИЕ, ОТМЕНА, ОПЦИИ, ПОКА, ОБНОВЛЕНИЕ
   Максимальное количество нападающих: 69
   Идентификация: CyI4 + nAkHrh4ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k
             3W + v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC
             HYWGCl0nB2sNsM9CG4hq + YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI =
   Идентификационная информация: https: // example.com / cert
   Тип содержимого: приложение / sdp
   Длина содержимого: xxxx
   Поддерживается: от-изменить

   v = 0
   o = - 1181923068 1181923196 В IP4 ua1.example.com
   s = example1
   c = IN IP4 ua1.example.com
   a = настройка: actpass
   a = отпечаток пальца: SHA-1 \
     4A: AD: B9: B1: 3F: 82: 18: 3B: 54: 02: 12: DF: 3E: 5D: 49: 6B: 19: E5: 7C: AB
   т = 0 0
   m = аудио 6056 RTP / AVP 0
   a = sendrecv
   a = tcap: 1 UDP / TLS / RTP / SAVP RTP / AVP
   а = pcfg: 1 t = 1

   Сообщение (3): ClientHello Bob -> Alice

      Предполагая, что личность Алисы действительна, строка 3 показывает, что Боб отправляет
      клиент DTLS Привет (я) непосредственно Алисе.В этом случае два DTLS
      Сообщения ClientHello будут отправлены Алисе: одно на
      ua1.example.com:6056 для RTP и еще один на порт 6057 для RTCP,
      но для компактности фигуры нарисована только одна стрелка.

   Сообщение (4): ServerHello + Сертификат Алиса -> Боб

      Алиса отправляет обратно ServerHello, Certificate и ServerHelloDone
      для ассоциаций RTP и RTCP. Обратите внимание, что тот же
      сертификат используется для ассоциаций RTP и RTCP. Если
      Мультиплексирование RTP / RTCP [RFC5761] использовалось только одним
      требуется ассоциация.Fischl, et al. Стандарты Track [Страница 17] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   Сообщение (5): Сертификат Боб -> Алиса

      Боб отправляет сертификат, ClientKeyExchange, CertificateVerify,
      change_cipher_spec и Finished для RTP и RTCP
      ассоциации. Снова обратите внимание, что Боб использует тот же сервер
      сертификат для обеих ассоциаций.

   Сообщение (6): Боб из ранних СМИ -> Алиса

      На этом этапе Боб может начать отправку ранних мультимедийных данных (RTP и RTCP) на
      Алиса.Обратите внимание, что Алиса еще не может доверять СМИ, так как
      отпечаток пальца еще не получен. Это отсутствие доверенных,
      защищенный носитель указывается Алисе через пользовательский интерфейс UA.

   Сообщение (7): Алиса закончила -> Боб

      После того, как Сообщение 7 получено Бобом, Алиса отправляет change_cipher_spec
      и готово.

   Сообщение (8): 200 ОК, Боб -> Алиса

      Когда Боб отвечает на звонок, Боб отправляет SIP-сообщение 200 OK, которое
      содержит отпечаток для сертификата Боба. Боб сигнализирует
      фактическая конфигурация транспортного протокола SRTP через DTLS в
      параметр acfg.SIP / 2.0 200 ОК
   Кому: ; tag = 6418913922105372816
   От: "Алиса" ; tag = 843c7b0b
   Через: SIP / 2.0 / TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk
   Через: SIP / 2.0 / TLS ua1.example.com; branch = z9hG4bK-0e53sadfkasldkfj
   Запись-Маршрут: 
   Call-ID: 6076913b1c39c212 @ REVMTEpG
   CSeq: 1 ПРИГЛАШАТЬ
   Контакты: 
   Тип содержимого: приложение / sdp
   Длина содержимого: xxxx
   Поддерживается: от-изменить













Fischl, et al.Стандарты Track [Страница 18] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   v = 0
   o = - 6418913922105372816 2105372818 В IP4 ua2.example.com
   s = example2
   c = IN IP4 ua2.example.com
   a = настройка: активна
   a = отпечаток пальца: SHA-1 \
     FF: FF: FF: B1: 3F: 82: 18: 3B: 54: 02: 12: DF: 3E: 5D: 49: 6B: 19: E5: 7C: AB
   т = 0 0
   m = аудио 12000 UDP / TLS / RTP / SAVP 0
   а = acfg: 1 t = 1

   Сообщение (9): 200 OK Прокси -> Алиса

      Алиса получает сообщение от своего прокси и проверяет
      сертификат, представленный в Сообщении 7.Конечная точка теперь показывает Алису
      что звонок как защищенный.

   Сообщение (10): RTP + RTCP Алиса -> Боб

      На этом этапе Алиса также может начать отправлять Бобу RTP и RTCP.

   Сообщение (11): ACK Алиса -> Боб

      Наконец, Алиса отправляет Бобу SIP ACK.

7.2. Базовый поток сообщений с подключенной идентификацией (RFC 4916)

   В предыдущем примере не было показано использование RFC 4916 для подключенных
   личность. Следующий пример делает:






















Fischl, et al. Стандарты Track [Страница 19] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   Алиса Прокси Боб
     | (1) ПРИГЛАСИТЬ | |
     | ----------------> | |
     | | (2) ПРИГЛАСИТЬ |
     | | -----------------> |
     | | (3) привет |
     | <----------------------------------- |
     | (4) привет | |
     | -----------------------------------> |
     | | (5) закончено |
     | <----------------------------------- |
     | | (6) СМИ |
     | <----------------------------------- |
     | (7) закончено | |
     | -----------------------------------> |
     | | (8) 200 ОК |
     | <----------------------------------- |
     | (9) ACK | |
     | -----------------------------------> |
     | | (10) ОБНОВЛЕНИЕ |
     | | <----------------- |
     | (11) ОБНОВЛЕНИЕ | |
     | <---------------- | |
     | (12) 200 ОК | |
     | ----------------> | |
     | | (13) 200 ОК |
     | | -----------------> |
     | | (14) СМИ |
     | <----------------------------------> |

   Первые 9 сообщений в этом примере такие же, как и раньше.Однако сообщения 10-13, выполняющие ОБНОВЛЕНИЕ RFC 4916, являются новыми.

   Сообщение (10): ОБНОВЛЕНИЕ Боб -> Прокси

      Боб отправляет Алисе RFC 4916 UPDATE. Это обновление содержит
      его отпечаток пальца. UPDATE Боба содержит тот же сеанс
      информация, которую он предоставил в своем 200 OK (Сообщение 8). Обратите внимание, что
      в принципе здесь можно использовать ОБНОВЛЕНИЕ для изменения сеанса
      параметры. Однако в этом случае он используется исключительно для
      подтвердите отпечаток пальца.










Fischl, et al.Стандарты Track [Страница 20] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   ОБНОВЛЕНИЕ sip: [email protected] SIP / 2.0
   Через: SIP / 2.0 / TLS ua2.example.com; branch = z9hG4bK-0e53sadfkasldkfj
   Кому: "Алиса" ; tag = 843c7b0b
   От ; tag = 6418913922105372816
   Маршрут: 
   Call-ID: 6076913b1c39c212 @ REVMTEpG
   CSeq: 2 ОБНОВЛЕНИЕ
   Контакты: 
   Тип содержимого: приложение / sdp
   Длина содержимого: xxxx
   Поддерживается: от-изменить
   Максимальное количество нападающих: 70

   v = 0
   o = - 6418913922105372816 2105372818 В IP4 ua2.example.com
   s = example2
   c = IN IP4 ua2.example.com
   a = настройка: активна
   a = отпечаток пальца: SHA-1 \
     FF: FF: FF: B1: 3F: 82: 18: 3B: 54: 02: 12: DF: 3E: 5D: 49: 6B: 19: E5: 7C: AB
   т = 0 0
   m = аудио 12000 UDP / TLS / RTP / SAVP 0
   а = acfg: 1 t = 1

   Сообщение (11): ОБНОВЛЕНИЕ прокси -> Алиса

      Это показывает, что ОБНОВЛЕНИЕ передается Алисе от Боба (и Алисы
      прокси).Обратите внимание, что прокси-сервер Боба вставил удостоверение и
      Заголовок Identity-Info. Как и выше, мы показываем только один элемент для обоих
      прокси в целях упрощения. Алиса проверяет
      личность предоставлена. (Примечание: настоящие идентификационные подписи здесь
      неверно и предоставлено только в качестве примера.)



















Fischl, et al. Стандарты Track [Страница 21] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   ОБНОВЛЕНИЕ sip: alice @ ua1.example.com SIP / 2.0
   Через: SIP / 2.0 / TLS proxy.example.com; branch = z9hG4bK-0e53sadfkasldkfj
   Через: SIP / 2.0 / TLS ua2.example.com; branch = z9hG4bK-0e53sadfkasldkfj
   Кому: "Алиса" ; tag = 843c7b0b
   От ; tag = 6418913922105372816
   Call-ID: 6076913b1c39c212 @ REVMTEpG
   CSeq: 2 ОБНОВЛЕНИЕ
   Контакты: 
   Тип содержимого: приложение / sdp
   Длина содержимого: xxxx
   Поддерживается: от-изменить
   Максимальное количество нападающих: 69
   Идентификация: CyI4 + nAkHrh4ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k
             3W + v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC
             HYWGCl0nB2sNsM9CG4hq + YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI =
   Идентификационная информация: https: // example.com / cert

   v = 0
   o = - 6418913922105372816 2105372818 В IP4 ua2.example.com
   s = example2
   c = IN IP4 ua2.example.com
   a = настройка: активна
   a = отпечаток пальца: SHA-1 \
     FF: FF: FF: B1: 3F: 82: 18: 3B: 54: 02: 12: DF: 3E: 5D: 49: 6B: 19: E5: 7C: AB
   т = 0 0
   m = аудио 12000 UDP / TLS / RTP / SAVP 0
   а = acfg: 1 t = 1

   Сообщение (12): 200 OK Алиса -> Боб

      Это показывает ответ Алисы 200 OK на UPDATE Боба. Потому что Боб
      просто отправил те же параметры сеанса, которые он отправил в своем 200 OK,
      Алиса может просто воспроизвести свой взгляд на параметры сеанса как
      хорошо.Fischl, et al. Стандарты Track [Страница 22] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   SIP / 2.0 200 ОК
   Кому: "Алиса" ; tag = 843c7b0b
   От ; tag = 6418913922105372816
   Через: SIP / 2.0 / TLS proxy.example.com; branch = z9hG4bK-0e53sadfkasldkfj
   Через: SIP / 2.0 / TLS ua2.example.com; branch = z9hG4bK-0e53sadfkasldkfj
   Call-ID: 6076913b1c39c212 @ REVMTEpG
   CSeq: 2 ОБНОВЛЕНИЕ
   Контакты: 
   Тип содержимого: приложение / sdp
   Длина содержимого: xxxx
   Поддерживается: от-изменить

   v = 0
   o = - 1181923068 1181923196 В IP4 ua2.example.com
   s = example1
   c = IN IP4 ua2.example.com
   a = настройка: actpass
   a = отпечаток пальца: SHA-1 \
     4A: AD: B9: B1: 3F: 82: 18: 3B: 54: 02: 12: DF: 3E: 5D: 49: 6B: 19: E5: 7C: AB
   т = 0 0
   m = аудио 6056 RTP / AVP 0
   a = sendrecv
   a = tcap: 1 UDP / TLS / RTP / SAVP RTP / AVP
   а = pcfg: 1 t = 1

7.3. Базовый поток сообщений с проверкой STUN на случай NAT

   В предыдущих примерах рукопожатие DTLS уже завершилось
   время, когда Алиса получает 200 OK Боба (8).Следовательно, нет проверки STUN
   отправлено. Однако, если бы у Алисы был NAT, то ClientHello Боба мог бы
   будут заблокированы этим NAT, и в этом случае Алиса отправит STUN
   проверьте, как описано в Разделе 6.7.1, после получения 200 OK, как показано
   ниже:


















Fischl, et al. Стандарты Track [Страница 23] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   Алиса Прокси Боб
     | (1) ПРИГЛАСИТЬ | |
     | ----------------> | |
     | | (2) ПРИГЛАСИТЬ |
     | | -----------------> |
     | | (3) привет |
     | X <----------------- |
     | | (4) 200 ОК |
     | <----------------------------------- |
     | (5) проверить | |
     | -----------------------------------> |
     | | (6) conn-response |
     | <----------------------------------- |
     | | (7) привет (rtx) |
     | <----------------------------------- |
     | (8) привет | |
     | -----------------------------------> |
     | | (9) закончено |
     | <----------------------------------- |
     | | (10) СМИ |
     | <----------------------------------- |
     | (11) закончено | |
     | -----------------------------------> |
     | | (11) СМИ |
     | -----------------------------------> |
     | (12) ACK | |
     | -----------------------------------> |

   Сообщения здесь такие же, как в первом примере (для
   простота в этом примере опускается ОБНОВЛЕНИЕ) со следующими тремя
   новые сообщения:

   Сообщение (5): STUN-проверка подключения Алиса -> Боб

      Раздел 6.7.1 описывает подход, позволяющий избежать взаимодействия SBC
      проблема, при которой конечные точки не поддерживают ICE. Алиса (пассивная
      конечная точка) отправляет Бобу проверку подключения STUN. Это открывает
      дыра в NAT / брандмауэре Алисы.

   Сообщение (6): ответ проверки подключения STUN Боб -> Алиса

      Боб (активная конечная точка) отправляет ответ на STUN
      проверка подключения (Сообщение 3) к Алисе. Это говорит Алисе, что
      ее проверка подключения прошла успешно, и она может остановить
      конечный автомат ретрансляции.Fischl, et al. Стандарты Track [Страница 24] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   Сообщение (7): Привет (повторная передача) Боб -> Алиса

      Боб повторно передает свой DTLS ClientHello, который теперь проходит через
      отверстие, созданное в брандмауэре Алисы. На этом этапе DTLS
      рукопожатие продолжается, как и раньше.

8. Соображения безопасности

   Среда DTLS или TLS, сигнализируемая с помощью SIP, требует способа гарантировать, что
   сертификаты участников обмена верны.Стандартная стратегия TLS / DTLS для аутентификации
   стороны должны предоставить серверу (и, возможно, клиенту) PKIX
   [RFC5280] сертификат. Затем клиент проверяет сертификат и
   проверяет, что имя в сертификате соответствует домену сервера
   имя. Это работает, потому что существует относительно небольшое количество
   серверы с четко определенными именами; ситуация, которая обычно не
   происходят в контексте VoIP.

   Дизайн, описанный в этом документе, предназначен для использования
   подлинность сигнального канала (при этом не требуется
   конфиденциальность).Пока каждая сторона соединения может проверить
   целостность SDP, полученного с другой стороны, затем DTLS
   рукопожатие нельзя перехватить с помощью атаки «злоумышленник посередине». Этот
   защита целостности легко обеспечивается вызывающим абонентом
   (см. Алиса Бобу в Разделе 7) через идентификатор SIP [RFC4474]
   механизм. Другие механизмы, такие как описанный механизм S / MIME
   в RFC 3261 или, возможно, будущие механизмы, которые еще предстоит определить, могут
   также служат этой цели.

   Хотя этот механизм еще можно использовать без такой целостности
   механизмов, обеспечиваемая безопасность ограничивается защитой от
   пассивная атака посредников.Активная атака на сигнализацию
   плюс активная атака на медиаплан может позволить злоумышленнику
   атаковать соединение (R-SIG-MEDIA в нотации [RFC5479]).

8.1. Личность респондента

   SIP Identity не поддерживает подписи в ответах. Идеально,
   Алиса хотела бы знать, что SDP Боба не был изменен
   и от кого он был, чтобы пользовательский агент Алисы мог указать
   Алиса, что был защищенный телефонный звонок Бобу. [RFC4916] определяет
   подход для UA, чтобы предоставить свою идентичность своему равноправному UA, и для
   этот идентификатор должен быть подписан службой аутентификации.За
   Например, используя этот подход, Боб отправляет ответ, а затем сразу
   следует ОБНОВЛЕНИЕ, которое включает отпечаток пальца и использует
   Механизм идентификации SIP для подтверждения того, что сообщение отправлено
   [email protected] Обратной стороной этого подхода является то, что он требует



Fischl, et al. Стандарты Track [Страница 25] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   дополнительный обход ОБНОВЛЕНИЯ. Однако это просто и безопасно
   даже если не всем прокси доверяют.В этом примере Боб
   нужно только доверять его прокси. Оференты ДОЛЖНЫ поддержать это
   механизм и ответчики ДОЛЖНЫ его использовать.

   В некоторых случаях ответчики не отправляют ОБНОВЛЕНИЕ, и во многих случаях
   некоторые носители будут отправлены до получения ОБНОВЛЕНИЯ. В этих
   случаях целостность отпечатка пальца от Боба к
   Алиса. При таком подходе злоумышленник, находящийся на пути передачи сигналов
   могли подделать отпечаток пальца и вставить себя как злоумышленник
   середина в СМИ.Алиса узнает, что у нее безопасный звонок
   с кем-то, но не мог знать, было ли это с Бобом или с человеком-в-
   средний. Боб знал бы, что происходит атака. Дело в том, что
   одна сторона может обнаружить эту атаку означает, что в большинстве случаев, когда Алиса
   и Боб оба желают, чтобы сообщения были зашифрованы, есть
   не проблема. Имейте в виду, что при любом из возможных подходов
   Боб всегда мог рассказать кому угодно о полученных СМИ. Мы
   делают предположение, что Боб также хочет безопасную связь.В этом случае Боб знает, что средства массовой информации не были подделаны.
   с третьей стороной или перехваченной, и что это
   [email protected] Алиса знает, что она с кем-то разговаривает и
   что кто бы это ни был, вероятно, проверил, что СМИ не
   перехвачены или подделаны. Этот подход, безусловно, меньше, чем
   идеален, но очень удобен во многих ситуациях.

8.2. SIPS

   Если SIP Identity не используется, но сигнализация защищена SIPS,
   гарантии безопасности слабее.Некоторая безопасность по-прежнему обеспечивается
   пока все прокси доверены. Это обеспечивает целостность
   отпечаток пальца в модели безопасности цепочки доверия. Обратите внимание, однако, что
   если прокси не доверяют, то обеспеченный уровень безопасности
   ограничено.

8.3. S / MIME

   RFC 3261 [RFC3261] определяет механизм безопасности S / MIME для SIP, который
   может использоваться для обозначения того, что отпечаток пальца принадлежит Бобу. Это бы
   быть в безопасности.

8.4. Непрерывность аутентификации

   Одним из желаемых свойств защищенной мультимедийной системы является обеспечение
   непрерывность аутентификации: возможность криптографического обеспечения
   что вы разговариваете с тем же человеком, что и раньше.С DTLS,
   непрерывность аутентификации достигается за счет того, что каждая сторона использует
   один и тот же открытый ключ / самозаверяющий сертификат для каждого подключения (не менее
   с данным одноранговым объектом). Затем становится возможным кэшировать



Fischl, et al. Стандарты Track [Страница 26] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   учетные данные (или его хэш) и убедитесь, что они не изменились. Таким образом, однажды
   установлено единое безопасное соединение, реализация
   может установить будущий безопасный канал даже перед лицом будущего
   небезопасная сигнализация.Чтобы обеспечить непрерывность аутентификации, реализации
   СЛЕДУЕТ пытаться сохранить постоянный долгосрочный ключ. Проверка
   реализации ДОЛЖНЫ поддерживать кэш ключа, используемого для каждого однорангового узла.
   identity и предупредить пользователя, если этот ключ изменится.

8.5. Короткая строка аутентификации

   Альтернативой, доступной Алисе и Бобу, является использование человеческой речи для
   проверять личность друг друга, а затем проверять личность друг друга
   отпечатки пальцев также с использованием человеческой речи. Предполагая, что это сложно
   олицетворять чужую речь и плавно изменять звук
   содержимое вызова, этот подход относительно безопасен.Не было бы
   быть эффективным, если использовались другие формы коммуникации, такие как
   видео или обмен мгновенными сообщениями. DTLS поддерживает этот режим работы.
   Минимальная длина безопасного отпечатка пальца составляет около 64 бит.

   ZRTP [AVT-ZRTP] включает режим короткой строки аутентификации (SAS) в
   которая генерируется уникальная битовая строка для каждого соединения как часть
   криптографическое рукопожатие. SAS может быть всего 25 бит и т.
   немного легче читать. DTLS изначально не поддерживает это
   Режим.В зависимости от уровня интереса к развертыванию расширение TLS
   [RFC5246] может обеспечить его поддержку. Обратите внимание, что только схемы SAS
   хорошо работают, когда конечные точки распознают голоса друг друга, что является
   неверно для многих настроек (например, колл-центров).

8.6. Пределы утверждений личности

   Когда RFC 4474 используется для привязки материала мультимедийных ключей к SIP
   сигнализация, заверения в происхождении и безопасности
   СМИ хороши ровно настолько, насколько хороши для сигнализации. Есть два
   важные случаи, на которые следует обратить внимание:

   o RFC 4474 предполагает, что прокси с сертификатом «пример.com "
      управляет пространством имен example.com. Следовательно, RFC 4474
      служба аутентификации, которая является авторитетной для данного пространства имен
      может контролировать, какому пользователю будет присвоено каждое имя. Таким образом
      служба аутентификации может принимать адрес, ранее назначенный
      Алиса и передайте его Бобу. Это намеренный дизайн
      особенность RFC 4474 и прямое следствие пространства имен SIP
      архитектура.






Fischl, et al. Стандарты Track [Страница 27] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   o Когда URI номера телефона (например,г.,
      'sip: [email protected]' или
      'sip: [email protected]; user = phone'), там
      не является структурной причиной полагать, что доменное имя
      авторитетный для данного номера телефона, хотя и индивидуальный
      прокси и UA могут иметь частные договоренности, которые позволяют им
      доверять другим доменам. Это структурная проблема в этой общественной
      Элементы коммутируемой телефонной сети (PSTN) доверяют утверждать
      их номер телефона правильно и что нет реального понятия
      данная сущность является авторитетной для некоторого числового пространства.В обоих случаях гарантии, предоставляемые DTLS-SRTP в
   условия целостности и конфиденциальности происхождения данных не обязательно
   лучше, чем SIP, обеспечивает целостность сигнализации, когда RFC 4474
   используемый. Поэтому разработчикам следует позаботиться о том, чтобы не указывать
   вводящая в заблуждение идентификационная информация однорангового узла в пользовательском интерфейсе. То есть,
   если идентичность партнера - sip: [email protected], это
   недостаточно, чтобы отобразить идентичность партнера как
   +17005551008, если не указано иное, что домен
   "Чикаго.example.com "доверено утверждать номера E.164, это
   утверждая. В случаях, когда UA может определить, что партнер
   идентификатор - это явно номер E.164, это может быть менее запутанным
   просто идентифицировать вызов как зашифрованный, но неизвестному узлу.

   Кроме того, некоторые промежуточные блоки (параллельные пользовательские агенты (B2BUA) и
   Пограничные контроллеры сеанса), как известно, изменяют части SIP
   сообщения, которые включены в вычисление подписи RFC 4474, таким образом
   нарушение подписи. Такого рода операция "человек посередине"
   именно такая модификация сообщения предназначена для RFC 4474
   обнаруживать.В тех случаях, когда самому среднему ящику разрешено
   генерировать действительные подписи RFC 4474 (например, он находится в том же
   административный домен в качестве службы аутентификации RFC 4474), затем
   он может создать новую подпись для измененного сообщения.
   В качестве альтернативы промежуточный ящик может иметь возможность подписаться с другим
   личность, которую разрешено утверждать. В противном случае получатель
   не может полагаться на утверждение идентификатора RFC 4474, а UA НЕ ДОЛЖЕН
   указать пользователю, что был установлен безопасный вызов
   заявленная личность.Реализации, настроенные только на
   устанавливать безопасные вызовы В этом случае СЛЕДУЕТ завершить вызов.

   Если SIP Identity или аналогичный механизм не используется, то только
   защита от злоумышленников, которые не могут активно изменять сигнализацию
   предоставлен. Хотя этот механизм все еще превосходит предыдущие,
   обеспечиваемая безопасность ниже той, которая предоставляется, если целостность
   предусмотрена сигнализация.






Fischl, et al. Стандарты Track [Страница 28] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


8.7. Сторонние сертификаты

   Эта спецификация не зависит от сертификатов, имеющихся у
   конечные точки поддаются независимой проверке (например, выпускаются
   доверенная третья сторона). Однако ограничений на такие
   сертификаты. Помимо сложности получения таких
   сертификаты, не ясно, что это за сертификаты
   будет содержать - RFC 3261 определяет соглашение для S / MIME
   сертификаты, которые также могут быть использованы здесь, но видел только
   минимальное развертывание.Однако в закрытых или полузакрытых контекстах, где
   такое соглашение может быть установлено, сторонние сертификаты могут
   уменьшить доверие даже к прокси в конечной точке
   домены.

8.8. Совершенная прямая секретность

   Одна из проблем, связанных с использованием долгосрочного ключа, заключается в том, что компрометация
   этот ключ может привести к компрометации прошлых коммуникаций. Чтобы
   предотвратить эту атаку, DTLS поддерживает режимы с Perfect Forward Secrecy
   с использованием наборов шифров Диффи-Хеллмана и Эллиптической кривой Диффи-Хеллмана.Когда используются эти режимы, система защищена от таких
   атаки. Обратите внимание, что компрометация долгосрочного ключа может привести к
   будущие активные атаки. Если это вызывает беспокойство, резервная аутентификация
   канал, например создание отпечатка пальца вручную или короткое
   строка аутентификации, должна использоваться.

9. Благодарности

   Каллен Дженнингс предоставил содержательный текст и комментарии к этому
   документ. Этот документ был полезен в ходе обсуждения с Франсуа.
   Одет, Нагендра Модадугу и Дэн Винг.Спасибо также за полезные
   комментарии Флемминга Андреасена, Джонатана Розенберга, Рохана Махи, Дэвида
   МакГрю, Мигель Гарсия, Штеффен Фрис, Брайан Стакер, Роберт Гилман,
   Дэвид Оран и Питер Шнайдер.

   Мы хотели бы поблагодарить Томаса Беллинга, Гюнтера Хорна, Штеффена Фриса,
   Брайан Стакер, Франсуа Оде, Дэн Винг, Яри Аркко и Веса
   Лехтовирте за их вклад в обход SBC.













Fischl, et al. Стандарты Track [Страница 29] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


10.Рекомендации

10.1. Нормативные ссылки

   [RFC2119] Брэднер, С. "Ключевые слова для использования в RFC для обозначения
              Уровни требований », BCP 14, RFC 2119, март 1997 г.

   [RFC3261] Розенберг, Дж., Шульцринн, Х., Камарилло, Г., Джонстон,
              А., Петерсон, Дж., Спаркс, Р., Хэндли, М. и Э.
              Школьник, "SIP: протокол инициации сеанса", RFC 3261,
              Июнь 2002 г.

   [RFC3264] Розенберг, Дж. И Х. Шульцринн, "Модель предложения / ответа
              с протоколом описания сеанса (SDP) », RFC 3264,
              Июнь 2002 г.[RFC5280] Купер, Д., Сантессон, С., Фаррелл, С., Бойен, С.,
              Р. Хаусли и У. Полк, "Открытый ключ Internet X.509
              Сертификат инфраструктуры и список отозванных сертификатов
              (CRL) Profile », RFC 5280, май 2008 г.

   [RFC3323] Петерсон, Дж., "Механизм конфиденциальности для сеанса
              Протокол инициации (SIP) », RFC 3323, ноябрь 2002 г.

   [RFC3550] Шульцринн, Х., Каснер, С., Фредерик, Р. и В.
              Якобсон, "RTP: транспортный протокол для реального времени
              Приложения », STD 64, RFC 3550, июль 2003 г.[RFC4145] Йон, Д. и Дж. Камарилло, "Транспорт мультимедиа на основе TCP в
              протокол описания сеанса (SDP) », RFC 4145,
              Сентябрь 2005 г.

   [RFC4347] Рескорла, Э. и Н. Модадугу, «Транспортный уровень дейтаграмм.
              Безопасность », RFC 4347, апрель 2006 г.

   [RFC4474] Петерсон, Дж. И К. Дженнингс, "Улучшения для
              Аутентифицированное управление идентификацией в сеансе
              Протокол инициации (SIP) », RFC 4474, август 2006 г.

   [RFC4566] Хэндли, М., Якобсон, В. и К. Перкинс, "SDP: сессия
              Описание протокола », RFC 4566, июль 2006 г.

   [RFC4572] Леннокс, Дж., "Ориентированный на соединение транспорт мультимедиа по
              Протокол безопасности транспортного уровня (TLS) в сеансе
              Протокол описания (SDP) », RFC 4572, июль 2006 г.






Fischl, et al. Стандарты Track [Страница 30] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   [RFC5389] Розенберг, Дж., Мэхи Р., Мэтьюз П. и Д. Винг,
              «Утилиты обхода сеанса для NAT (STUN)», RFC 5389,
              Октябрь 2008 г.

10.2. Информативные ссылки

   [RFC4571] Лаззаро, Дж., "Фрейминг транспортного протокола реального времени (RTP)"
              и RTP Control Protocol (RTCP) пакетов через
              Транспорт, ориентированный на соединение », RFC 4571, июль 2006 г.

   [RFC3325] Дженнингс, К., Петерсон, Дж. И М. Уотсон, "Частный
              Расширения протокола инициации сеанса (SIP) для
              Подтвержденная идентификация в надежных сетях », RFC 3325,
              Ноябрь 2002 г.[RFC5245] Розенберг, Дж., «Создание интерактивного подключения.
              (ICE): протокол для транслятора сетевых адресов (NAT)
              Обход протоколов предложений / ответов ", RFC 5245, апрель
              2010 г.

   [RFC4567] Аркко, Дж., Линдхольм, Ф., Наслунд, М., Норрман, К., и Э.
              Каррара, "Расширения управления ключами для сеанса
              Описание протокола (SDP) и потоковая передача в реальном времени
              Протокол (RTSP) », RFC 4567, июль 2006 г.

   [RFC4568] Андреасен, Ф., Баугер М. и Д. Винг, "Сессия
              Описание протокола (SDP) Описание безопасности для мультимедиа
              Streams », RFC 4568, июль 2006 г.

   [AVT-ZRTP] Циммерманн, П., Джонстон, А., и Дж. Каллас, "ZRTP: СМИ
              Соглашение о ключах пути для безопасного RTP », Работа в процессе,
              Март 2009 г.

   [SRTP-EKT] МакГрю, Д., Андреасен, Ф., и Л. Дондети, «Зашифрованный ключ.
              Transport for Secure RTP », Работа в процессе, март 2009 г.

   [RFC5764] МакГрю, Д. и Э. Рескорла, «Транспортный уровень дейтаграмм.
              Расширение безопасности (DTLS) для создания ключей безопасности
              Протокол передачи в реальном времени (SRTP) », RFC 5764, май 2010 г.[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet,
              «Требования и анализ управления безопасностью медиа»
              Протоколы », RFC 5479, март 2009 г.








Fischl, et al. Стандарты Track [Страница 31] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


   [MMUSIC-SDP]
              Андреасен, Ф., "Согласование возможностей SDP", Работа
              в процессе, февраль 2010 г.

   [RFC5761] Перкинс, К.и М. Вестерлунд, "Мультиплексирование данных RTP и
              Пакеты управления на одном порте », RFC 5761, апрель 2010 г.

   [RFC3262] Розенберг, Дж. И Х. Шульцринн, "Надежность
              Предварительные ответы в протоколе инициации сеанса
              (SIP) ", RFC 3262, июнь 2002 г.

   [RFC5246] Диркс, Т. и Э. Рескорла, «Безопасность транспортного уровня.
              (TLS) Protocol Version 1.2 », RFC 5246, август 2008 г.

   [RFC4916] Элвелл, Дж., "Connected Identity in the Session Initiative"
              Протокол (SIP) », RFC 4916, июнь 2007 г.[RFC3711] Баугер, М., МакГрю, Д., Наслунд, М., Каррара, Э. и К.
              Норрман, "Безопасный транспортный протокол в реальном времени (SRTP)",
              RFC 3711, март 2004 г.

   [RFC3830] Аркко, Дж., Каррара, Э., Линдхольм, Ф., Наслунд, М., и К.
              Норрман, "МИКИ: Мультимедийный Интернет-ключ", RFC 3830,
              Август 2004 г.

   [SIPPING-SRTP]
              Винг Д., Одет Ф., Фрис С., Чофениг Х. и А.
              Джонстон, "Безопасная запись мультимедиа и перекодирование с помощью
              Протокол инициации сеанса ", Работа в процессе,
              Октябрь 2008 г.[КЛЮЧ-ТРАНСПОРТ]
              Винг, Д., «DTLS-SRTP Key Transport (KTR)», Work
              в процессе, март 2009 г.

   [МУЗЫКА-МЕДИА]
              Стакер Б. и Х. Чофениг, "Анализ мидлбокса"
              Взаимодействия для обмена данными по сигнальному протоколу
              Путь СМИ », Работа в процессе, март 2009 г.

   [RFC5767] Мунаката, М., Шуберт, С., и Т. Охба, "Пользователь-агент-
              Управляемый механизм конфиденциальности для SIP », RFC 5767, апрель 2010 г.









Fischl, et al.Стандарты Track [Страница 32] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


Приложение A. Анализ требований

   [RFC5479] описывает требования безопасности для мультимедийных ключей. Этот
   Раздел оценивает это предложение по каждому требованию.

А.1. Форкинг и ретаргетинг (R-FORK-RETARGET, R-BEST-SECURE,
      R-DISTINCT)

   В этом документе предложение SDP (в ПРИГЛАШЕНИИ) просто
   реклама способности обеспечивать безопасность.Эта реклама
   не зависит от личности общающегося партнера, поэтому разветвление
   и ретаргетинг работает, когда все конечные точки будут выполнять SRTP. Когда смесь
   присутствуют конечные точки SRTP и не-SRTP, мы используем SDP
   механизм возможностей, который в настоящее время определяется [MMUSIC-SDP] для
   прозрачно согласовывать вопросы безопасности там, где это возможно. Потому что DTLS
   устанавливает новый ключ для каждого сеанса, только объект, с которым
   звонок наконец установлен, получает ключи шифрования носителя (R3).А.2. Отчетливые криптографические контексты (R-DISTINCT)

   DTLS выполняет новое рукопожатие DTLS с каждой конечной точкой, что
   устанавливает отдельные ключи и криптографические контексты для каждого
   конечная точка.

А.3. Повторное использование контекста безопасности (R-REUSE)

   DTLS позволяет возобновлять сеансы с «возобновлением сеанса TLS»
   функциональность. Эту функцию можно использовать для уменьшения количества
   криптографические вычисления, которые необходимо выполнить, когда два одноранговых узла
   возобновить общение. См. [RFC5764] для получения дополнительной информации о сеансе.
   возобновление в этом контексте.А.4. Обрезка (R-ИЗБЕЖАНИЕ-ОБРЕЗАНИЕ)

   Поскольку создание ключей происходит в медиаплоскости, СМИ нуждаются в
   не обрезаться до получения ответа SDP. Обратите внимание, однако,
   что только конфиденциальность обеспечивается до тех пор, пока оферент не получит
   ответ: отвечающий знает, что они не отправляют данные
   злоумышленник, но предлагающий не может знать, что он получает данные
   от ответчика.

А.5. Пассивные атаки на медиа-путь (R-PASS-MEDIA)

   Алгоритмы открытого ключа, используемые наборами шифров DTLS, такими как RSA,
   Диффи-Хеллмана и Эллиптическая кривая Диффи-Хеллмана защищены от
   пассивные атаки.Fischl, et al. Стандарты Track [Страница 33] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


А.6. Пассивные атаки на сигнальном тракте (R-PASS-SIG)

   DTLS обеспечивает защиту от пассивных атак злоумышленников на
   путь передачи сигналов, поскольку с помощью SIP осуществляется обмен только отпечатком пальца
   сигнализация.

А.7. (R-SIG-MEDIA, R-ACT-ACT)

   Злоумышленник, контролирующий медиаканал, но не сигнализацию
   канал может выполнить атаку MITM на рукопожатие DTLS, но это
   изменить сертификаты, которые вызовут проверку отпечатка пальца
   потерпеть поражение.Таким образом, любая успешная атака требует, чтобы злоумышленник изменил
   сигнальные сообщения о замене отпечатков пальцев.

   Если используется идентификатор RFC 4474 или аналогичный механизм, злоумышленник
   кто контролирует канал сигнализации в любой точке между прокси
   выполнение идентификационных подписей не может изменить отпечатки пальцев
   без признания подписи недействительной. Таким образом, даже злоумышленник, который
   управляет как сигнальными, так и медиа-путями, не может успешно атаковать
   медиа-трафик. Обратите внимание, что канал между UA и
   служба аутентификации ДОЛЖНА быть защищена, а служба аутентификации
   ДОЛЖЕН проверить идентичность UA, чтобы этот механизм был
   безопасный.Обратите внимание, что злоумышленник, контролирующий службу аутентификации, может
   выдавать себя за UA, используя эту службу аутентификации. Это
   предполагаемая функция SIP Identity - служба аутентификации владеет
   пространство имен и, следовательно, определяет, какой пользователь имеет какое удостоверение.

А.8. Привязка к идентификаторам (R-ID-BINDING)

   Когда сквозной механизм, такой как SIP-Identity [RFC4474] и SIP-
   Connected-Identity [RFC4916] или S / MIME, они связывают
   отпечатки сертификата конечной точки на адрес От: в
   сигнализация.Отпечаток пальца покрыт идентификационной подписью.
   Когда используются другие механизмы (например, SIPS), то привязка
   соответственно слабее.

А.9. Совершенная прямая секретность (R-PFS)

   DTLS поддерживает шифр Диффи-Хеллмана и эллиптической кривой Диффи-Хеллмана
   наборы, которые предоставляют PFS.









Fischl, et al. Стандарты Track [Страница 34] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


А.10. Согласование алгоритма (R-COMPUTE)

   DTLS согласовывает наборы шифров перед выполнением значительных
   криптографические вычисления и, следовательно, поддерживает алгоритм
   переговоры и несколько наборов шифров без дополнительных
   вычислительные затраты.А.11. Проверка действительности RTP (R-RTP-VALID)

   Пакеты DTLS не проходят проверку действительности RTP. Первый байт
   Пакет DTLS - это тип содержимого и все текущие типы содержимого DTLS.
   установить первые два бита в ноль, что приведет к нулевой версии;
   таким образом, провал первой проверки действительности. Пакеты DTLS также могут быть
   отличается от пакетов STUN. См. [RFC5764] для получения подробной информации о
   демультиплексирование.

А.12. Сторонние сертификаты (R-CERTS, R-EXISTING)

   Сторонние сертификаты не требуются, потому что сигнализация (например,г.,
   [RFC4474]) используется для аутентификации сертификатов, используемых DTLS.
   Однако, если стороны совместно используют инфраструктуру аутентификации,
   совместим с TLS (сторонние сертификаты или общие ключи),
   может быть использован.

А.13. FIPS 140-2 (R-FIPS)

   Реализации TLS уже могут быть одобрены FIPS 140-2 и
   используемые здесь алгоритмы соответствуют утверждению DTLS и
   DTLS-SRTP.

А.14. Связь между обменом ключами и сигнализацией SIP (R-ASSOC)

   Обмен сигналами связан с обменом управления ключами с использованием
   отпечатки пальцев, переносимые в SIP, и сертификаты обмениваются в
   DTLS.А.15. Уязвимость, вызывающая отказ в обслуживании (R-DOS)

   DTLS предлагает некоторую степень защиты от отказа в обслуживании (DoS) в качестве
   встроенная функция (см. раздел 4.2.1 [RFC4347]).

А.16. Крипто-гибкость (R-AGILITY)

   DTLS позволяет согласовывать наборы шифров и, следовательно, новые алгоритмы
   могут быть развернуты постепенно. Работы по замене фиксированного MD5 / SHA-1
   функция деривации ключа продолжается.





Fischl, et al. Стандарты Track [Страница 35] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


А.17. Защита от понижения версии (R-DOWNGRADE)

   DTLS обеспечивает защиту от атак с понижением версии, поскольку
   выбор предлагаемых наборов шифров подтверждается на более позднем этапе
   рукопожатия. Эта защита эффективна, если только противник
   может взломать набор шифров в режиме реального времени. RFC 4474 может
   не дать активному злоумышленнику на пути передачи сигналов понизить версию
   звонок из SRTP в RTP.

А.18. Согласование безопасности мультимедиа (R-NEGOTIATE)

   DTLS позволяет пользовательскому агенту согласовывать параметры безопасности мультимедиа для
   каждое индивидуальное занятие.А.19. Независимость протокола сигнализации (R-OTHER-SIGNALING)

   Структура DTLS-SRTP не полагается на SIP; каждый протокол, который
   возможность обмена отпечатком пальца, и описание мультимедиа может быть
   обеспечен.

А.20. Медиа-запись (R-RECORDING)

   Расширение, см. [SIPPING-SRTP], было указано для поддержки мультимедиа.
   запись, которая не требует, чтобы посредники действовали как MITM.

   Когда запись на носитель осуществляется посредниками, им необходимо действовать.
   как MITM.

А.21. Взаимодействие с посредниками (R-TRANSCODER)

   Для взаимодействия с любым посредником, который перекодирует
   СМИ, транскодер должен иметь доступ к ключевому материалу и быть
   рассматривается как конечная точка для целей этого документа.А.22. Терминация шлюза PSTN (R-PSTN)

   Инфраструктура DTLS-SRTP позволяет завершать защиту мультимедиа на
   Шлюз PSTN. Это не обеспечивает сквозную безопасность, но
   соответствует целям безопасности этой структуры, потому что
   шлюз уполномочен говорить от имени пространства имен PSTN.

А.23. R-ALLOW-RTP

   DTLS-SRTP позволяет получать мультимедийные данные RTP вызывающей стороной до тех пор, пока
   SRTP согласован с отвечающим, после чего SRTP
   предпочтительнее RTP.





Fischl, et al.Стандарты Track [Страница 36] 

RFC 5763 DTLS-SRTP Framework, май 2010 г.


А.24. R-HERFP

   Проблема разветвления неоднородного ответа на ошибку (HERFP) не является
   применимо к DTLS-SRTP, поскольку протокол обмена ключами будет
   выполняется на пути к носителю, поэтому сообщения об ошибках
   общаются по этому пути, и прокси не должны продвигаться
   их.

Адреса авторов

   Джейсон Фишл
   Skype, Inc.
   2145 Гамильтон авенюСан-Хосе, Калифорния 95135
   Соединенные Штаты Америки

   Телефон: + 1-415-692-1760
   Электронная почта: [email protected]


   Ханнес Чофениг
   Nokia Siemens Networks
   Linnoitustie 6
   Эспоо, 02600
   Финляндия

   Телефон: +358 (50) 4871445
   Электронная почта: [email protected]
   URI: http://www.tschofenig.priv.at


   Эрик Рескорла
   RTFM, Inc.
   2064 Edgewood Drive
   Пало-Альто, Калифорния 94303
   Соединенные Штаты Америки

   Электронная почта: [email protected]













Fischl, et al. Standards Track [Страница 37]

 

Разметка HTML, созданная rfcmarkup 1.129d, доступно с https://tools.ietf.org/tools/rfcmarkup/

Istio / Выбор протокола

  1. Istio
  2. Документы
  3. Операции
  4. Конфигурация
  5. Управление трафиком
  6. Выбор протокола

Istio поддерживает проксирование любого TCP-трафика. Сюда входят HTTP, HTTPS, gRPC, а также необработанные протоколы TCP. Протокол должен быть определен для предоставления дополнительных возможностей, таких как маршрутизация и расширенные метрики.Это может быть сделано автоматически или явно указано.

Протоколы, не основанные на TCP, такие как UDP, не проксируются. Эти протоколы будут продолжать работать в обычном режиме, без любой перехват прокси Istio, но не может использоваться только в компонентах прокси, таких как входные или исходящие шлюзы.

Автоматический выбор протокола

Istio может автоматически обнаруживать трафик HTTP и HTTP / 2. Если протокол не может быть определен автоматически, трафик будет рассматриваться как обычный трафик TCP.Протоколы

Server First, такие как MySQL, несовместимы с автоматическим выбором протокола. См. Раздел «Первые протоколы сервера» для получения дополнительной информации.

Явный выбор протокола

Протоколы можно указать вручную в определении службы.

Это можно настроить двумя способами:

  • По имени порта: name: [- ] .
  • В Kubernetes 1.18+ в поле appProtocol : appProtocol: .

Поддерживаются следующие протоколы:

  • http
  • http2
  • https
  • tcp
  • tls
  • grpc
  • grpc mongo
  • mysql *
  • redis *
  • udp (UDP не будет проксироваться, но порт может быть явно объявлен как UDP)

* Эти протоколы отключены по умолчанию, чтобы избежать случайного включения экспериментальные особенности.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *