5. Соображения безопасности
Протокол COPS предоставляет объект Integrity, который может обеспечить аутентификацию, целостность сообщения, и предотвратить подмену с использованием записи предыдущих сообщений. Все реализации COPS должны поддерживать работу с объектом COPS Integrity. Чтобы гарантировать, что клиент (PEP) обменивается с корректным сервером политики (PDP), необходима аутентификация PEP и PDP, с использованием общего ключа (secret), и согласованная проверка того, что соединение является корректным. Ключ используется в сочетании с содержимым сообщения COPS, чтобы вычислить дайджест сообщения, который является частью объекта Integrity. Объект Integrity затем используется для проверки всех сообщений COPS, посланных через TCP-соединение между PEP и PDP.
Объект COPS Integrity предоставляет также порядковый номер, чтобы исключить атаки откликов. PDP выбирает начальный порядковый номер для PEP, а PEP выбирает начальный порядковый номер для PDP. Эти начальные номера затем инкрементируются каждым последующим сообщением, пересланным через данное соединение в соответствующем направлении. Исходный порядковый номер должен быть выбран так, чтобы для заданного ключа в процессе монотонного приращения не получалось идентичных номеров.
Безопасность обмена между клиентом (PEP) и сервером (PDP) может быть обеспечена за счет IP Security [IPSEC]. В этом случае, заголовок аутентификации IPSEC (AH) должен использоваться для проверки правильности соединения; кроме того, безопасное поле данных IPSEC ESP (Encapsulation Security Payload) может использоваться для реализации, как безопасности, так и конфиденциальности.
TLS [Transport Layer Security] может использоваться, как для обеспечения соединения, так и для гарантии конфиденциальности.
Тип клиента идентифицирует Client-type приложения, к которому относится сообщение. Значения типа клиента в диапазоне 0x0001-0x3FFF зарезервированы для статуса необходимой спецификации (Specification Required), как это определено [IANA-CONSIDERATIONS]. Эти значения должны быть зарегистрированы IANA и их поведение и применимость должны быть описана в документе расширения COPS.
Значения типа клиента (Client-type) в диапазоне 0x4000 - 0x7FFF зарезервированы для частного использования, как это определено в [IANA-CONSIDERATIONS].
Значения типа клиента в диапазоне 0x8000 - 0xFFFF относятся к типу “первым пришел – первым обслужен”, как это определено в [IANA-CONSIDERATIONS].
6. Соображения безопасности
Система CyberCash для работы с кредитными картами версии 0.8 предоставляет достаточную защиту платежных сообщений, как это описано в разделах 1.2, 2.2.4 и 2.2.5. Система не обеспечивает достаточной защиты от нечестного продавца (здесь вне конкуренции протокол SET). Следует не выпускать из внимания ЭВМ, на которых работают различные части системы, в противном случае нельзя добиться приемлемого уровня безопасности.
Ссылки
[ISO 4217] |
Codes for the representation of currencies and funds |
[ISO 8583] |
Financial transaction card originated messages - Interchange message specifications, 1993-12-15. |
[RFC-822] |
Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC- 822, UDEL, August 1982. |
[RFC-1521] |
Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC- 1521, Bellcore, Innosoft, September 1993. |
[RFC-1766] |
Alvestrand, H., "Tags for the Identification of Languages", UNINETT, March 1995. |