Securing Mobile IPv6 Route Optimization Using a Static Shared Key

정리 : 20070221 by 임헌정
http://www.4ellene.net
급하게 만든 허접 번역 입니다. 오역이 많습니다.

[번역] Securing Mobile IPv6 Route Optimization Using a Stati..

1. Introduction

This specification introduces an alternative, low-latency security

mechanism for protecting signaling related to the route optimization

in Mobile IPv6.

이 문서에서는 MIPv6의 RO과정에서 메시지 보호를 위한 low-latency한 보안 메커니즘을 소개 하려 한다.

The default mechanism specified in [1] uses a

periodic return routability test to verify both the "right" of the

mobile node to use a specific home address, as well as the validity

of the claimed care-of address. That mechanism requires no

configuration and no trusted entities beyond the mobile node's home

agent.

[1]의 방식은 주기적인 RR테스트를 통해서 MN를 점검하는 방식을 사용하였다.

이방식은 설정이나 MN의 HA에 대한 신뢰 엔티티가 필요 하지 않았다.

The mechanism specified in this document, however, requires the

configuration of a shared secret between mobile node and its

correspondent node.

이 문서에서 제안하는 메커니즘은 MN과 CN과의 공유키 설정이 필요하다.

As a result, messages relating to the

routability tests can be omitted, leading to significantly smaller

latency. In addition, the right to use a specific home address is

ensured in a stronger manner than in [1].

결과 적으로 RR테스트가 생략되어 레턴시가 줄어 들게 된다. 부가적으로 HoA를 사용할수 있는 권한도 [1]방식에 비해 stronger manner한다.

On the other hand, the

applicability of this mechanisms is limited due to the need for

preconfiguration. This mechanism is also limited to use only in

scenarios where mobile nodes can be trusted not to misbehave, as the

validity of the claimed care-of addresses is not verified.

반면에 사전 설정이 필요 하므로 활용도에 있어서는 제한적이다. 또한, MN가 잘못된 동작을 안한다는 가정하에서만 가능하다. 잘못된 동작이란 validity of the claimed care-of addresses is not verified.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in RFC 2119 [2]. Other

terminology is used as already defined in [1].

2. Applicability Statement

This mechanism is useful in scenarios where the following conditions

are all met:

아래 내용은 이 메커니즘이 동작 하기 위한 요구 사항들을 정의한 것이다.

- Mobile node and correspondent node are administered within the

same domain.

mn과 cn은 같은 도메인 안에 있어야 함

- The correspondent node has good reason to trust the actions of

the mobile node. In particular, the correspondent node needs to

be certain that the mobile node will not launch flooding attacks

against a third party as described in [5].

CN은 MN의 동작을 무조건 신뢰하여야 한다. 구체적으로, CN은 MN가 [5]에서 설명하는 플러딩 공격을 하지 않는 다고 확신 해야 한다.

- The configuration effort related to this mechanism is acceptable.

Users MUST be able to generate/select a sufficiently good value

for Kcn (see [3])

이 메커니즘에서 필요한 설정을 당연히 수행 하여야 한다. 사용자는 Kcn에 충분한 값을 생성하거나 선택 하여야 한다.

- There is a desire to take advantage of higher efficiency or

greater assurance with regards to the correctness of the home

address offered via this mechanism.

이 메커니즘에 위해서 제공되는 HoA보다 효율적이고 정확성에 대해 보다 확실성을 가지는 것을 이용고자 하여야 한다.

- This mechanism is used only for authenticating Binding Update

messages (and not, e.g., data), so the total volume of traffic is

low (see RFC 4107 [4], and the discussion in section 4).

이 메커니즘은 BU메시지의 인증에만 사용되어야 한다.(데이터 인증에 사용 불가), 그래야만 전체적인 트래픽의 양이 줄어 든다.

This mechanism can also be useful in software development, testing,

and diagnostics related to mobility signaling.

이 메커니즘은 모빌리티 신호 전송 소프트웨어 개발이나 태스트, 진단에 유용하게 사용될수 있다.

Generally speaking, the required level of trust that the

correspondent node needs for enabling a precomputable Kbm with a

mobile node is more often found within relatively small, closed

groups of users who are personally familiar with each other, or who

have some external basis for establishing trustworthy interactions.

일반적으로 CN이 MN의 Kbm을 미리 계산하는데 필요한 신뢰의 요구 레벨은 상대적으로 작고, 사용자의 가까운 그룹이다.

A typical example scenario where this mechanism is applicable is

within a corporation, or between specific users. Application in the

general Internet is typically not possible due to the effort that is

required to manually configure the correspondent nodes.

이 메커니즘이 사용되기 적절한 곳은 회사나 특정한 두 개인 사이이다. 인터넷에서의 일반적 어플리케이션은 직접 CN을 수정하여야 하는 문제 때문에 적당하지 않다.

Application at a public network operator is typically not possible due to

requirements placed on the trustworthiness of mobile nodes.

공개 네트워크 오퍼레이터의 어플리케이션으로 사용하는 것도 적절하지 않은데 그 이유는 MN이 신뢰할만한 곳에 위치 하여야 하기 때문이다.

3. Precomputing a Binding Management Key (Kbm)

A mobile node and a correspondent node may preconfigure data useful

for creating a Binding Management Key (Kbm), which can then be used

for authorizing binding management messages, especially Binding

Update and Binding Acknowledgement messages. This data is as

follows:

MN과 CN은 바인딩 관리 키(Kbm)생성을 위해 미리 데이터를 설정해두어야 한다. 이 데이터는 BU, BUAck등의 바인딩 관련 메시지를 허가(=authorizing) 할때 사용한다. 이렇게 설정해야 하는 데이터는 아래와 같다.

- A shared key (Kcn) used to generate keygen tokens, at least 20

octets long

- A nonce for use when generating the care-of keygen token

- A nonce for use when generating the home keygen token

The keygen tokens MUST be generated from Kcn and the nonces as

specified in Mobile IPv6 [1] return routability. Likewise, the

binding management key Kbm must subsequently be generated from the

keygen tokens in the same way as specified in Mobile IPv6 [1].

키젠토큰은 MIPv6 RR에 정의된것처럼 Kcn과 nonces값을 가지고 생성되어야 한다.동시에 바인딩 메니져 키 Kbm도 MIPv6에서 정의된것처럼 키젠 토큰을 통해서 생성되어야 한다.

The

preconfigured data is associated to the mobile node's home address.

Kcn MUST be generated with sufficient randomness (see RFC 4086 [3]).

미리 설정할 데이터는 MN의 HoA와 연관되어서 설정되어야 한다. Kcn은 충분한 랜덤값으로 생성되어야 한다.

Replay protection for Binding Update messages using Kbm computed from

the preconfigured data depends upon the value of the Sequence Number

field in the Binding Update.

Kbm을 이용한 BU msg.재전송 방지는 미리 정의된 데이터를 가지고 구현하다. 이 데이터의의 값은 BU의 seq# 필드값을 참조하여 구한다.

If the correspondent node does not

maintain information about the recently used values of that field,

then there may be an opportunity for a malicious node to replay old

Binding Update messages and fool the correspondent node into routing

toward an old care-of address.

만약 CN이 필드의 최근 정보를 가지고 있다면, 악의적 노드가 이를 악용할 가능성이 있다.

For this reason, a correspondent node

that uses a precomputable Kbm also MUST keep track of the most recent

value of the Sequence Number field of Binding Update messages using

the precomputable Kbm value (for example, by committing it to stable

storage).

이러한 이유 때문에 미리 계산된 Kbm을 이용하는 CN은 BU메시지의 Seq# 필드의 최근 사용한 정보를 보관 하고 있어야 한다.

When a Binding Update is to be authenticated using such a

precomputable binding key (Kbm), the Binding Authorization Data

suboption MUST be present. The Nonce Indices option SHOULD NOT be

present. If it is present, the nonce indices supplied SHOULD be

ignored and are not included as part of the calculation for the

authentication data, which is to be performed exactly as specified in

[1].

인증에 미리 계산된 바인딩 키(Kbm)을 이용한 바인딩 업데이트시 Binding Authorization Data의 옵션에 체크가 되어 있어야 한다. Nonce를 지칭하는 옵션은 설정되어 있으면 안된다. 만약 설정되어 있더라도 nonce값은 무시되며 인증데이터 계산시 고려 하지 않는다.

4. Security Considerations

A correspondent node and a mobile node may use a precomputable

binding management key (Kbm) to manage the authentication

requirements for binding cache management messages.

CN과 MN은 미리 계산된 바인딩 관리 키를 사용하여 binding cache management message를 필요한 인증 요구사항을 관리 한다.

Such keys must

be handled carefully to avoid inadvertent exposure to the threats

outlined in [5]. Many requirements listed in this document are

intended to ensure the safety of the manual configuration. In

particular, Kcn MUST be generated with sufficient randomness (see RFC

4086 [3]), as noted in Section 3.

이런 키 값들은 외부 침입자들에게 노출되지 않도록 조심 하여야 한다. 이 문서에서 정의하고 있는 많은 요구사항들은 설정들에 대해 안정하게 보관하는것에 초점을 두고 있다.

Manually configured keys MUST be used in conformance with RFC 4107

[4]. Used according to the applicability statement, and with the

other security measures mandated in this specification, the keys will

satisfy the properties in that document.

직접 설정된 키들은 rfc4170와 상응해야 한다. 또한 문서에서 요구하는 여러 요구사항을 만족 해야 한다.

In order to ensure

protection against dictionary attacks, the configured security

information is intended to be used ONLY for authenticating Binding

Update messages.

사전 공격을 방지하기 위해서는 설정된 보안 정보는 바인딩 업데이트 메시지 인증시만 사용되어야 한다.

A mobile node MUST use a different value for Kcn for each node in its

Binding Update List, and a correspondent node MUST ensure that every

mobile node uses a different value of Kcn.

MN는 자신이 가지고 있는 바인딩 업데이트 리스트의 각 노드마다 서로 다른 Kcn값을 사용해야 한다. 그리고 CN은 모든 MN이 서로 다른 Kcn을 가지고 있다고 확신 해야 한다.

This ensures that the

sender of a Binding Update can always be uniquely determined. This

is necessary, as this authorization method does not provide any

guarantee that the given care-of address is legitimate.

BU 전송자는 독특하게 선택 될수 이다는 점도 간과하지 말아야 한다. 왜냐 하면, 이런 authorization방식은 주어진 CoA주소가 합당한 것이진 확인할수 없다.

For the same

reason, this method SHOULD only be applied between nodes that are

under the same administration. The return routability procedure is

RECOMMENDED for all general use and MUST be the default, unless the

user explicitly overrides this by entering the aforementioned

preconfigured data for a particular peer.

이와 비슷한 이유로 이 방식은 동일한 관리 상에 있는 노드들 끼리에게만 적용될수 있다. RR 동작은 모든 일반적 사용시 적당하다. 그리고 특별한 이유가 없다면 기본 방식으로 설정되어야 한다.

Replay protection for the Binding Authorization Data option

authentication mechanism is provided by the Sequence Number field of

the Binding Update.

Binding Authorization 데이터 옵션의 인증 메커니즘에 대한 재전송 방지는 바인딩 업데이트의 Seq# 필드를 통해서 가능하다.

This method of providing replay protection fails

when the Binding Update sequence numbers cycle through the 16 bit

counter (i.e., not more than 65,536 distinct uses of Kbm), or if the

sequence numbers are not protected against reboots.

이런 재전송 방지도 실패할때가 있는데 바로 Seq# 16bit 카운터이상 오버 했을 경우이다. 또는 재 부팅으로 인해 seq# 정보가 지워 졌을 경우 이다.

If the mobile

node were to send a fresh Binding Update to its correspondent node

every hour, 24 hours a day, every day of the year, this would require

changing keys every 7 years.

만약 MN이 매시간 마다 새 바인딩 업데이트를 전송시 매 7년마다 키를 교환하여야 한다

Even if the mobile node were to do so

every minute, this would provide protection for over a month. Given

typical mobility patterns, there is little danger of replay problems;

만약 매 분마다 바인딩 업데이트를 한다면 한달동안은 protection을 할수 있다. 하지만 이런 패턴이 이라면 재전송관련 위험성을 가지고 있다.

nodes for which problems might arise are expected to use methods

other than manual configuration for Kcn and the associated nonces.

이런 문제점을 가진 노드는 직접 Kcn이나 관련 nonce를 설정하는 방식말고 다른걸 사용하여야 한다.

When the Sequence Number field rolls over, the parties SHOULD

configure a new value for Kcn, so that new Kbm values will be

computed.

Seq# 가 제한 값을 넘긴다면 parties는 새 Kcn값을 설정하여야 한다. 그래므로 새 Kbm값을 설정 하여야 한다.

If a correspondent node does NOT keep track of the sequence number

for Binding Update messages from a particular mobile node, then the

correspondent node could be fooled into accepting an old value for

the mobile node's care-of address.

만약 CN이 MN의 바인딩 업데이트 메시지의 seq#를 저장하고 있지 않는다면 CN은 MN의 과거의 CoA주소를 이용한 공격에 당할수 있다.

In the unlikely event that this

address was reallocated to another IPv6 node in the meantime, that

IPv6 node would then be vulnerable to unwanted traffic emanating from

the correspondent node.

일반적이지 않은 경우지만 이 주소가 다른 IPv6노드에게 재 할당될 수가 있다. 이렇게 되면 IPv6노드는 CN이 전송하는 원하지 않는 트래픽으로 인해 피해를 볼수 있다.

Note that where a node has been configured to use the mechanism

specified in this document with a particular peer, it SHOULD NOT

attempt to use another mechanism, even if the peer requests this or

claims not to support the mechanism in this document. This is

necessary in order to prevent bidding down attacks.

특정 노드와 통신하기 위해서 이 문서에서 제안하는 메커니즘을 원하는 노드가 있다면, 그 특정 노드가 다른 메커니즘을 원하더라도 다른 메커니즘과 병행하여서 사용하면 안된다. 이것은 bidding down 공격을 막기 위해서 이다.

There is no upper bound on the lifetime defined for the precomputable

Kbm. As noted, the key is very likely to be quite secure over the

lifetime of the security association and usefulness of applications

between a mobile node and correspondent node that fit the terms

specified in section 2.

미리 계산된 Kbm을 위해 정의된 Lifetime의 시간 제안은 없다. 이야기 했듯이 키정보는 SA의 lifetime동안 안전하게 관리 되어야 한다.