The M-KE definition in 4.1 sets which authentication methods may be used by the Mobile Client and Server. This chapter, gives the motivation, why the usage is restricted exactly to these combinations.
The M-VPN is not starting from scratch, i.e. building new infrastructure. There is already an existing infrastructure and well-established protocols. Most deployments will use M-VPN in conjunction with already existing elements with PPP, Radius AAA etc. The good integration between all these protocols is the main requirements for building secure network. Generally, a big part of vulnerabilities is because of poor integration between the different applications. The application may work secure separately form each other, but the joint integration may suffer form vulnerabilities. The main problems are wrong assumption between the applications. For example using IPSec to protect SIP (VoIP). The IPSec session authenticates the hosts and not the SIP application. The SIP URI is not authorized and authenticate by the IPSec session, thus the SIP application may use bogus URI. The Integration of different security application must be analysed very carefully and it is target in this chapter.
A typical layer structure of M-VPN with PPP is shown in Figure 6.1. There are generally three layers having authentication abilities, thus M-KE, L2TP and PPP, see Figure 6.2. The administrator has the possibility to set authentication at each of these three layers. It is a task of the security policy by the administrator to consider influences before switching features on or off. The problem is not limited to M-VPN, nut holds for all applications with overlapping functionality.
Authentication, authorisation and key generation in different layers can bring many problems for the real deployment. The first reason is matching of the ID between the layers.
Figure 6.1: Layers L2TP and M-VPN
UDP M-SEP IP UDP L2TP PPP Data UDP/TCP IP M-KE UDP IP M-SEP M-KE User packet L2TP/PPP encapsulation Transport (mobile) Mobility and security
6.1 Authentication at different layers 98
For example: the x509 certificate used M-KE is issued to the user Alice, but the user authenticates himself as Bob in the following the PPP negotiation. Clearly, there is a mismatching of the ID and this can be an abuse from insider. It can be compared to a case when one person’s driving license and the ID card are valid, but issued on different names. Mismatching of the ID’s does not mean automatically an attack. This can be a legal case of inheriting administrative rights. In the last example, the certificate can authenticate the host and the PPP authenticates the user. This is obviously legal case.
First, there must be a clear policy of mapping of ID between the different layers. The layers are dependent from each other concerning the security. The interaction between the layers is not very easy, since the authentication methods can even have different syntaxes of the ID. For example: the PPP username is built typically as “username@domain”, unfortunately the x501 structure has a different way of building the ID, for example “CN=user, OU=Arcor”. It even does not allow “@” in the Distinguished Name according the x501 specification. The matching is a major problem and must be carefully considered in the local security policy. It cannot be defined globally in a standard, since there are different cases with different layer combinations.
The second potential problem arises when the authentication and the key generation are done at different layers. The Diffie-Hellman (DH) key exchange does not deliver authentication and therefore, it is vulnerable to man-in-the-middle attacks. The exchanged DH values must be authenticated for this reason. This is typically done by exchanging authenticated hash values. A problem is, for example, when the authentication is made in PPP layer and the DH exchange is made in M-KE. The DH is not authenticated, so the M-KE is not secure against man-in-the-middle. Therefore, the PPP connection over M-SE is unprotected against man-in-the-middle. The reason is that the PPP session is started only after successful M-KE negotiation and establishment of M-SE. It is not possible to use PPP authentication for protection of M-KE, since M-KE is finished before PPP begins (causality principle). There must be always authentication at M-KE level. If authentication is required in a PPP session, then there must be two authentications at M-KE and at PPP.
One possible solution in the example could be client authentication at PPP layer and server authentication at M-KE. The user PPP authentication can be made with a password. The M-KE server authenticates by certificate. The DH is authenticated by the server credentials (see 6.4.4). A manipulation can be noticed by the client because the server sends to the client a signed HMAC from all exchanges packets (containing also the DH public values). The server cannot notice any manipulation, since the client cannot build authenticated HMAC. The man-in-the-middle attack can be prevented only by the client. Naturally, the client has an interest of preventing manipulation. The exchange work in the same way as e-banking, thus server side certificate in TLS and client password in HTTP layer.
Figure 6.2: Authentication possibilities L2TP over M-SE
L2TP PPP M-KE EAP Password Signature Signature/Password (EAP-TTLS) Password (EAP-MD5)
Shared secret (EAP-PSK)
Shared secret
Signature (EAP-TLS)
MS-CHAPv2 (EAP-MSCHAPv2)
SIM cart (EAP-SIM)
IKEv2 (EAP-IKEv2) Password Password (PAP,CHAP etc) EAP Signature/Password (EAP-TTLS) Password (EAP-MD5)
Shared secret (EAP-PSK) Signature (EAP-TLS) MS-CHAPv2 (EAP-MSCHAPv2) SIM cart(EAP-SIM) other IKEv2 (EAP-IKEv2) other Signature Shared secret EAP ….. Signature Shared secret EAP …..