FCPAP: Fibre Channel Password Authentication and ...

FCPAP: Fibre Channel Password Authentication and Key Exchange Protocol Claudio DeSanti, Fabio Maino Andiamo Systems, Inc. (T11/02-512v1)

1.0 Overview FCPAP is a general password based authentication and key exchange protocol which may be used to mutually authenticate two FC_Port in a Fibre Channel Fabric. It may be used to authenticate:

• E_Port to E_Port • Domain Controller to Domain Controller • N_Port to E_Port • N_Port to N_Port When the authentication occurs between two Switches the protocol is encapsulated in a SW_ILS. When N_Ports are involved the protocol is encapsulated in a ELS. The message payload content is the same in the two cases. This version of the FCPAP protocol is based on SRP, the Secure Remote Password Authentication and Key Exchange System, as defined in RFC 2945 [RFC2945]. The name of the SRP method defined by this document is SRP-DHGRP1-SHA1. This method is assigned ID 1 (one), and ID 0 (zero) is reserved. The method specified in this document provides mutual authentication and key exchange between the parties involved. Other methods could be defined to provide Security Association management between the two parties, using a limited subset of the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]. Other authentication and key exchange mechanisms could be defined as well, if required. For the SRP-DHGRP1-SHA1 the value of the large prime N and of the generator g are fixed, and the hash function used is SHA1 [SHA]. The value of N is equal to: 2^1024 - 2^960 - 1 + 2^64 * floor(2^894 Pi + 129093)

(EQ 1)

Its hexadecimal value is: FFFFFFFF 020BBEA6 4FE1356D EE386BFB

FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF. (EQ 2)

The generator g is equal to 5.

1

The group used is derived from the Second Oakley Group of the IKE specification [RFC2409], and was originally generated by Richard Schroeppel at the University of Arizona. Properties of this prime are described in [RFC2412]. Given the modulo above, and the fact the g must be a generator, 5 is choosen as the value of g. A generic SRP authentication process is composed of six (or more) message exchanges, as shown in Figure 1 below (See [02-071v0] for further details).

U =

x_SRP_INIT x_SRP_ACC

A = g^a % N

x_SRP_ESC x_SRP_ACC

M1 =

s =

B = (v +g^b) % N

x_SRP_COMP x_SRP_ACC

M2 =

FIGURE 1. Generic SRP Authentication and Key Exchange

The FCPAP protocol collapses the first four messages in one single exchange, as suggested in [RFC2954], and then it consists of four different messages:

• FCPAP_Init • FCPAP_Accept • FCPAP_Complete • FCPAP_Done

2

Figure 2 below shows the FCPAP authentication process and the content of the messages.

U = , A = g^a % N

FCPAP_Init s = , B = (v +g^b) % N FCPAP_Acc

M1 =

FCPAP_Comp M2 = FCPAP_Done

FIGURE 2. FCPAP Authentication and Key Exchange

The end point that acts as the SRP client sends an Authentication Initialization (FCPAP_Init) request. The FCPAP_Accept response has the same form of the FCPAP_Init message and allows the authentication procedure to continue. Note: Following RFC2945 requirements, the FCPAP_Init message shall be rejected if the value A % N is zero. Also the client side must abort if the value B % N is zero. In either case the client side starts again with an FCPAP_Init. The FCPAP_Init/FCPAP_Accept step provides mutual authentication between the two entities. The initiating entity demonstrates that it has the password and the responding entity demonstrates that it has the password verifier. The authentication process completes when the client sends an Authentication Complete (FCPAP_Comp) request and receives the FCPAP_Done response. Note: Following RFC2945 requirements, the host must reject the FCPAP_Comp if the hash value of M does not match its value. It must not respond with its hash of the session key. In this case the client side must start again with an FCPAP_Init. When the FCPAP protocol is successful the two parties are authenticated, and a session key has been selected. Extending FCPAP with a subset of the ISAKMP messages, will enable SA management and the ESP_Header (see [02-070v3]) could be used to protect subsequent FC frames exchanged between the two end-points.

1.1 Bi-directional Authentication with Shared Verifiers When the same verifier is shared across multiple parties, such as in the case of a Fabric where all the Switches share the same authentication database, FCPAP provides mutual authentication between the Switch that is joining the Fabric, and the Fabric as a group. This may be acceptable in most environments, but in other ones bi-directional authentication may be required. As an example, when a Switch joins a Fabric, the authentication of the Fabric as 3

a group may not be considered enough, and the joining Switch may want verify the identity of the actual Switch to which it is connected to. In these cases bi-directional authentication can be obtained augmenting the SRP exchange as described in [02-609v0]. The initiator of the FCPAP exchange will insert the salt of the responder in the initial message, to indicate that bi-directional authentication is required. Responder and Initiator will then compute the bi-directional shared key K as the ex-or of the key resulting by the SRP exponentiation in the two directions, as described in [02-609v0]. The computation of M1 and M2 will be also done using the bi-directional shared key K, proving not only that the initiator has its own password and the responder the right verifier, but also that the responder has its own password.

2.0 Message Format The FCPAP protocol shares a common basic AUTH message format with the Fibre Channel Certificate Authentication Protocol FCCAP. The format of the AUTH Sequence Payload is shown in Table 1. TABLE 1. AUTH Message Format Size Bytes

Item AUTH Code

1

Reserved

1

AUTH Command Code

1

Protocol Version

1

Command Dependent Information

n

AUTH Code: When the AUTH message is encoded as an SW_ILS, for authentication between Switches, this value is set to hex‘40’. When the AUTH message is encoded as an ELS, for authentication with N_Ports involved, this value is set to TBD. AUTH Command Code: This field contains an 8-bit unsigned binary integer that specifies the AUTH command that is to be transported from the originating end-point to the destination end-point. The command values used by FCPAP are shown in Table 2. TABLE 2. AUTH Command Codes Value (hex)

Description

00

Reserved

05

AUTH_Reject

06

FCPAP_Init

07

FCPAP_Accept

08

FCPAP_Comp

09

FCPAP_Done

0A

ISAKMP_Message

other values

Reserved

Protocol Version: This field contains an 8-bit unsigned binary integer that specifies the version of the AUTH protocol. This value shall be set to hex’01’.

4

Command Dependent Information: Contains information related to the specific AUTH command specified in the AUTH Command Code field.

2.1 FCPAP_Init message The FCPAP_Init message contains this information:

• Flags field. • Authentication method identifier - the identifier of the authentication and key exchange method used. The method defined by this document is SRP-DHGRP1-SHA1. Its value is set to hex ‘01’ and the value ‘00’ is reserved.

• SRP Username - a Fibre Channel Name_Identifier (WWN). • SRP salt length. • SRP salt value. • Authentication data length. • Authentication data value - the SRP A value (A is the public key corresponding to the ephemeral private key a, generate randomly and not publicly revealed).

• An optional ISAKMP field for SA management. The format of the FCPAP_Init dependent information is shown in Table 3. TABLE 3. FCPAP_Init Information

Item

Size (Bytes)

Flags

1

Authentication method identifier

1

Reserved

2

FC Name_Identifier

8

Reserved

2

SRP salt length

2

SRP salt value

x

Reserved

2

Authentication data length

2

Authentication data value

x

Optional ISAKMP field

y

For the SRP-DHGRP1-SHA1 authentication method, the authentication data (the SRP A value) is 128 bytes long. If the initiator does not require bi-directional authentication, the SRP salt lenght shall be set to 0. Otherwise the initiator shall include the responder’s salt in the SRP salt value field, and the SRP computation of the shared key K shal be performed as described in [02-609v0].

5

2.1.1 Flags The flags field makes the protocol extensible. The values currently defined follow:

• Bit 0- ISAKMP field present. Set to 1 if the ISAKMP field is present in the payload, otherwise set to 0.

• Bit 1-7 Reserved. 2.2 FCPAP_Accept message The FCPAP_Accept message contains this information:

• Flags field (see 2.1.1). • SRP salt length. • SRP salt value. • Authentication data length. • Authentication data content - the SRP B value (B is the public key corresponding to the ephemeral private key b, generate randomly and not publicly revealed).

• An optional ISAKMP field for SA management. The format of the FCPAP_Accept dependent information is shown in Table 4. TABLE 4. FCPAP_Accept Information

Item

Size (Bytes)

Flags

1

Reserved

1

SRP salt length

2

SRP salt value

x

Reserved

2

Authentication data length

2

Authentication data value

y

Optional ISAKMP field

z

For the SRP-DHGRP1-SHA1 authentication method, the authentication data (the SRP B value) is 128 bytes long. The salt is a random number used to generate a different password verifiers in the SRP protocol. As specified in [RFC2945] salt and verifier are generated as follows: salt = random() x = SHA1 (salt | SHA1 (FC Name_Identifier | ‘:’ | password)) verifier = v = g^x % N

(EQ 3)

The | symbol indicates string concatenation, the ^ operator is the exponentiation operation, and the % operator is the integer remainder operation. Most implementations perform the exponentiation and remainder in a single stage to avoid generating unwieldy intermediate results. Note that the 160-bit output of SHA1 is implicitly converted to an integer before it is operated upon. 6

Implementations often use strings of characters as passwords, salts and verifiers. This document doesn’t pose constraints on the format or size of passwords, salts and verifier, but section 2 of [RFC2945] specifies one method by which integers can be converted into strings of bytes and vice versa.

2.3 FCPAP_Comp message The FCPAP_Comp message contains this information:

• Flags field (see 2.1.1). • Authentication data length. • Authentication data content - This is the M1 hash of the SRP mechanism computed over the public keys A and B, and the shared session key K.

• An optional ISAKMP field for SA management. The format of the FCPAP_Comp dependent information is shown in Table 5. TABLE 5. FCPAP_Comp Information

Size (Bytes)

Item Flags

1

Reserved

1

Authentication data length

2

Authentication data value

y

Optional ISAKMP field

z

Since the hash function of the SRP-DHGRP1-SHA1 is 160 bits long, the Authentication Data size will be 20 bytes (160 bit).

2.4 FCPAP_Done message The FCPAP_Done message contains this information:

• Flags field (no flags values are defined for the FCPAP_Done message) • Authentication data length. • Authentication data content - This is the M2 hash of the SRP mechanism computed over the public key A, the value M1 received with the FCPAP_Comp message and the shared session key K. The format of the FCPAP_Done dependent information is shown in Table 6. TABLE 6. FCPAP_Done Information

Item

Size (Bytes)

Flags

1

Reserved

1

7

TABLE 6. FCPAP_Done Information

Item

Size (Bytes)

Authentication data length

2

Authentication data value

y

Since the hash function of the SRP-DHGRP1-SHA1 is 160 bits long, the Authentication Data size will be 20 bytes (160 bit).

2.5 ISAKMP_Message As explained in Section 3.0, autonomuos ISAKMP messages may be exchanged between two end-points in order to manage Security Associations. The format of the ISAKMP_Message dependent information is shown in Table 7. TABLE 7. ISAKMP_Message Information

Item

Size (Bytes)

ISAKMP field

z

2.6 AUTH_Reject message The AUTH_Reject is sent from one end-point to another to indicate that the authentication and key exchange has completed unsuccessfully. The format of the AUTH_Reject dependent information is shown in Table 8. TABLE 8. AUTH_Reject Information

Item

Size (Bytes)

Reason Code

1

Reserved

3

Reason Code: The reason why the authentication request has been rejected. Values are shown in Table 9. TABLE 9. AUTH_Reject Values

Value (hex)

Description

00

Reserved

01

Authentication Failed

02

Authentication Mechanism not supported

other values

Reserved

8

3.0 Security Association Management FCPAP provides mutual authentication and the exchange of an ephemeral key that is the result of the SRP exchange. In order to enable ESP encapsulation the two parties need to agree on a common set of security parameters that characterize the security associations (SAs) that will be used to secure the traffic exchanged between the two nodes. An example of such parameters are the Secure Parameter Index (SPI) that identify the SA or the algorythms used to encrypt and authenticate the FC frames (e.g. 3DES and HMAC-SHA1). FCPAP leverages the format of messages defined by the Internent Security Association and Key Management Protocol (ISAKMP) [RFC2408] to negotiate, establish, modify, and delete SAs. While ISAKMP defines the format of messages, FCPAP uses a subset of the Internet Key Exchange (IKE) [RFC2409] protocol to effectively negotiate SAs. Specifically in what is called IKE Phase 1, a secure authenticated channel is established between the two parties, and an ISAKMP SA is established in order to negotiate the other SAs that will be used to protect the traffic between the two end-points. During the IKE Phase 2, that may repeat many times, SAs are actually negotiated on behalf of other services over an FCsec channel protected by the ISAKMP SA (e.g. to protect SW_ILS traffic). All the ISAKMP messages exchanged are authenticated using the SRP shared key that has been agreed during the authentication phase. Two alternatives are possible for the Phase 1 exchange: it may be embedded in the SRP authentication messages, or it may be a separated exchange that follows the SRP authentication. Figure 3 shows the first alternative where an extended FCPAP exchange (carryying the optional ISAKMP message) is performed to authenticate the two entities and, after the SRPshared key has been established, perform an IKE Phase 1 exchange that enables the ISAKMP SA. Using that SA the IKE Phase 2 exchange is performed to acrivate a SA that, in the example, is applied to the SW_ILS traffic. Note that the IKE Phase 2 exchange is protected (encrypted) by the ISAKMP SA, while the SW_ILS traffic is protected by the specific SA setup in the phase 2 exchange.

9

SRP-shared Key

FCPAP and IKE Phase 1 Exchange

SRP-shared Key

ISAKMP_SA is now active

IKE Phase 2 exchange Specific SA is now active (e.g SW_ILS) SW_ILS traffic protected

FIGURE 3. IKE Phase 1 embedded in the FCPAP exchange

Figure 4 shows the second alternative where an explicit IKE Phase 1 exchange occurs after the FCPAP exchange has been completed and the SRP-shared key has been established. In this case the ISAKMP SA is established with an explicit set of messages (ISAKMP_Messages) during the Phase 1 exchange. After Phase 1 has been completed exactly the same messages as in the example above are exchanged.

SRP-shared Key

FCPAP exchange

IKE Phase1 exchange

IKE Phase 2 exchange

SRP-shared Key

ISAKMP_SA is now active

Specific SA is now active (e.g SW_ILS)

SW_ILS traffic protected

FIGURE 4. IKE Phase 1 as a set of messages after the FCPAP exchange

3.1 Phase 1 As described above the IKE Phase1 exchange may be embedded in the FCPAP authentication exchange or happen after the FCPAP exchange has been terminated.

10

3.1.1 Phase 1 embedded in FCPAP Figure 5 shows how an IKE Phase 1 exchange is embedded in FCPAP. The optional ISAKMP field is added to the first three messages of the FCPAP exchange, and the content of each ISAKMP field is specified on the ISAKMP Header (Hdr) that prefix the optional ISAKMP field. The ISAKMP messages exchanged are conformant to the IKE Phase 1 Aggressive Mode, specified in RFC 2409. The ISAKMP field of the FCPAP_Init message contains:

• The ISAKMP header, as specified in RFC 2408 • A number of proposed SA transforms • A Nonce Ni that provides anti-replay protection The ISAKMP field of the FCPAP_Acc message contains:

• The ISAKMP header, as specified in RFC 2408 • The accepted SA transform, between the one proposed with the FCPAP_Init • A Nonce Nr that provides anti-replay protection • A keyed hash of the ISAKMP message, computed using the SRP-shared key established during the current FCPAP exchange

Initiator

Responder

FCPAP_Init, HDR, SA, Ni

ISAKMP Header SA parameters Anti-Replay Protection

FCPAP_Acc, HDR, SA, Nr, HASH_R

Integrity Protection

FCPAP_Comp, HDR, HASH_I

FCPAP_Done

FIGURE 5. FCPAP extended with support for IKE Phase 1

The extensions of the FCPAP_Comp message contains:

• The ISAKMP header, as specified in RFC 2408 • A keyed hash of the ISAKMP message, computed using the SRP-shared key established during the current FCPAP exchange

11

The format of the ISAKMP field is defined in RFC 2408, and as an example the ISAKMP extension of the FCPAP_Init message is shown in Figure 6. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Aggressive Mode ~ ~ and Next Payload of ISA_SA ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Situation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_TRANS ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #1 ! KEY_OAKLEY | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ prefered SA attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_NONCE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #2 ! KEY_OAKLEY | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ alternate SA attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Ni (from initiator) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

FIGURE 6. Example of ISAKMP extensions of the FCPAP_Init message

3.1.2 Autonomous Phase 1 Exchange It is possible to activate FCsec protection even after an FCPAP exchange has been completed without ISAKMP extensions. In this case a complete IKE Phase1 Aggressive Mode exchange will be perfomed, encapsulated in the ISAKMP_Message (see 2.5). Figure 7 shows the actual sequence of messages exchanged. The only difference with what is specified in RFC 2408 and RFC2409 are the identifiers (IDii and IDIr) that are the nodes WWNs. The shared key used to compute the Message Integrity Checks HASH_R and HASH_I is the SRP shared key exchanged during the FCPAP authentication.

12

In itia to r

R e sp o n d e r H D R , S A , K E , N i, ID ii

H D R , S A , K E , N r, ID ir, H A S H _ R

HDR, HASH_I

FIGURE 7. Autonomous IKE Phase 1 Exchange

3.2 Phase 2 After a Phase 1 exchange has been completed, either subsequent or embedded into the FCPAP exchange, a IKE Phase 2 exchange can be accomplished to create a new SA between two nodes. Of the possible Phase 2 exchanges specified by IKE, only Quick Mode is implemented, as specified in Figure 8. H D R , H A S H (1 ), S A , N i

H D R , H A S H (2 ), S A , N r

H D R , H A S H (3 )

FIGURE 8. IKE Phase 2 Exchange

The ISAKMP messages, whose format is specified in RFC 2408 and RFC 2409, are encapsulated in the ISAKMP_Message (see 2.5). The authentication fields HASH() are computed using the SRP-shared key exchanged during the initial FCPAP exchange.

13

4.0 References [02-070v3] C. DeSanti, “Definition of the ESP_Header”, T11 document 02-070v3 [02-071v0] C. DeSanti, F. Maino et. al. “FCsec: a security framework for Fibre Channel”, T11 document 02-071v0 [02-609v0] F. Maino, “SRP Bi-directional Authentication with Shared Verifiers”, T11 document 02-609v0 [RFC2412] H. Orman, "The Oakley Key Determination Protocol", RFC 2412, November 1998. [RFC2408] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", IETF RFC 2408, November 1998. [RFC2409] D. Harkins, D. Carrel, “The Internet Key Exchange”, IETF RFC 2409, November 1998 [RFC2945] T. Wu. “The SRP Authentication and Key Exchange System”, IETF RFC 2945, September 2000 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institute of Standards and Technology, U.S. Department of Commerce, May 1994

14