rfc4178.The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Ne

第30卷 第2期2008年2月武 汉 理 工 大 学 学 报JOURNAL OF WUHAN UNIVERSITY OF TECHNOLOGY Vol.30 No.2 Feb.2008IPv6 IPSec 在企业VPN 网络中的应用研究吉顺如(上海电机学院电子信息学院,上海200240)摘 要: IPv6作为下一代互联网的基础协议,在互连的基础上考虑了安全的因素,IPv 6把IP Sec 作为它的一个组成部分,利用IPSec 协议实现了网络层的加密与认证。

文中着重对I Pv6网络安全协议I PSec 进行了分析,通过利用IP Sec 安全隧道技术,在Inter net 公用网上建立安全的企业虚拟专用网络,从而有效地保障了企业间的通信安全。

关键词: IPSec; IK E; VP N; 安全隧道中图分类号: T P 393文献标识码: A 文章编号:1671 4431(2008)02 0129 04Research and Application of IPv6Security Protocols inEnterprise Virtual Private NetworkJI Shun ru(School of Electronic Info rmat ion,Shang hai Dianji U niversity,Shanghai 200240,China)Abstract: As the basic protocol in the next gener at ion I nternet,IP v6considered the factor of security in addit ion to inter connectivity.I Pv6used IP Sec (IP Security )to implement encryption and authentication at the network layer.T he thesis em phasized to analyze the I Pv6security protocols.T he Secure enterprise virtual private networ k was established in the Internet by using IPSec securit y tunnel.T hereby the informat ion could be transferr ed secur ely between the enterprises.Key words: IP Sec; IK E; V PN ; security tunnel收稿日期:2007 10 19.作者简介:吉顺如(1967 ),女,硕士.E mail:jishunru@随着Internet 的迅猛发展和国际经济一体化的发展趋势,企业内部及企业间通过网络传递信息的需求越来越多。

Network Working Group J. Arkko Request for Comments: 4187 Ericsson Category: Informational H. Haverinen Nokia January 2006 Extensible Authentication Protocol Method for 3rd GenerationAuthentication and Key Agreement (EAP-AKA)Status of This MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2006).IESG NoteThe EAP-AKA protocol was developed by 3GPP. The documentation ofEAP-AKA is provided as information to the Internet community. While the EAP WG has verified that EAP-AKA is compatible with EAP asdefined in RFC 3748, no other review has been done, includingvalidation of the security claims. The IETF has also not reviewedthe security of the underlying UMTS AKA algorithms.AbstractThis document specifies an Extensible Authentication Protocol (EAP)mechanism for authentication and session key distribution that usesthe Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal MobileTelecommunications System (UMTS) and CDMA2000. AKA is based onsymmetric keys, and typically runs in a Subscriber Identity Module,which is a UMTS Subscriber Identity Module, USIM, or a (Removable)User Identity Module, (R)UIM, similar to a smart card.EAP-AKA includes optional identity privacy support, optional resultindications, and an optional fast re-authentication procedure.Arkko & Haverinen Informational [Page 1]Table of Contents1. Introduction and Motivation (4)2. Terms and Conventions Used in This Document (5)3. Protocol Overview (9)4. Operation (15)4.1. Identity Management (15)4.1.1. Format, Generation, and Usage of Peer Identities (15)4.1.2. Communicating the Peer Identity to the Server (21)4.1.3. Choice of Identity for the EAP-Response/Identity (23)4.1.4. Server Operation in the Beginning ofEAP-AKA Exchange (23)4.1.5. Processing of EAP-Request/AKA-Identity bythe Peer (24)4.1.6. Attacks against Identity Privacy (25)4.1.7. Processing of AT_IDENTITY by the Server (26)4.2. Message Sequence Examples (Informative) (27)4.2.1. Usage of AT_ANY_ID_REQ (27)4.2.2. Fall Back on Full Authentication (28)4.2.3. Requesting the Permanent Identity 1 (29)4.2.4. Requesting the Permanent Identity 2 (30)4.2.5. Three EAP/AKA-Identity Round Trips (30)5. Fast Re-Authentication (32)5.1. General (32)5.2. Comparison to AKA (33)5.3. Fast Re-Authentication Identity (33)5.4. Fast Re-Authentication Procedure (35)5.5. Fast Re-Authentication Procedure when Counter isToo Small (37)6. EAP-AKA Notifications (38)6.1. General (38)6.2. Result Indications (39)6.3. Error Cases (40)6.3.1. Peer Operation (41)6.3.2. Server Operation (41)6.3.3. EAP-Failure (42)6.3.4. EAP-Success (42)7. Key Generation (43)8. Message Format and Protocol Extensibility (45)8.1. Message Format (45)8.2. Protocol Extensibility (47)9. Messages (48)9.1. EAP-Request/AKA-Identity (48)9.2. EAP-Response/AKA-Identity (48)9.3. EAP-Request/AKA-Challenge (49)9.4. EAP-Response/AKA-Challenge (49)9.5. EAP-Response/AKA-Authentication-Reject (50)9.6. EAP-Response/AKA-Synchronization-Failure (50)Arkko & Haverinen Informational [Page 2]9.7. EAP-Request/AKA-Reauthentication (50)9.8. EAP-Response/AKA-Reauthentication (51)9.9. EAP-Response/AKA-Client-Error (52)9.10. EAP-Request/AKA-Notification (52)9.11. EAP-Response/AKA-Notification (52)10. Attributes (53)10.1. Table of Attributes (53)10.2. AT_PERMANENT_ID_REQ (54)10.3. AT_ANY_ID_REQ (54)10.4. AT_FULLAUTH_ID_REQ (54)10.5. AT_IDENTITY (55)10.6. AT_RAND (55)10.7. AT_AUTN (56)10.8. AT_RES (56)10.9. AT_AUTS (57)10.10. AT_NEXT_PSEUDONYM (57)10.11. AT_NEXT_REAUTH_ID (58)10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING (58)10.13. AT_CHECKCODE (60)10.14. AT_RESULT_IND (62)10.15. AT_MAC (63)10.16. AT_COUNTER (64)10.17. AT_COUNTER_TOO_SMALL (64)10.18. AT_NONCE_S (65)10.19. AT_NOTIFICATION (65)10.20. AT_CLIENT_ERROR_CODE (66)11. IANA and Protocol Numbering Considerations (66)12. Security Considerations (68)12.1. Identity Protection (69)12.2. Mutual Authentication (69)12.3. Flooding the Authentication Centre (69)12.4. Key Derivation (70)12.5. Brute-Force and Dictionary Attacks (70)12.6. Protection, Replay Protection, and Confidentiality (70)12.7. Negotiation Attacks (71)12.8. Protected Result Indications (72)12.9. Man-in-the-Middle Attacks (72)12.10. Generating Random Numbers (73)13. Security Claims (73)14. Acknowledgements and Contributions (74)15. References (74)15.1. Normative References (74)15.2. Informative References (76)Appendix A. Pseudo-Random Number Generator (77)Arkko & Haverinen Informational [Page 3]1. Introduction and MotivationThis document specifies an Extensible Authentication Protocol (EAP)mechanism for authentication and session key distribution that usesthe 3rd generation Authentication and Key Agreement mechanism,specified for Universal Mobile Telecommunications System (UMTS) in[TS33.102] and for CDMA2000 in [S.S0055-A]. UMTS and CDMA2000 areglobal 3rd generation mobile network standards that use the same AKA mechanism.2nd generation mobile networks and 3rd generation mobile networks use different authentication and key agreement mechanisms. The GlobalSystem for Mobile communications (GSM) is a 2nd generation mobilenetwork standard, and EAP-SIM [EAP-SIM] specifies an EAP mechanismthat is based on the GSM authentication and key agreement primitives. AKA is based on challenge-response mechanisms and symmetriccryptography. AKA typically runs in a UMTS Subscriber IdentityModule (USIM) or a CDMA2000 (Removable) User Identity Module((R)UIM). In this document, both modules are referred to as identity modules. Compared to the 2nd generation mechanisms such as GSM AKA, the 3rd generation AKA provides substantially longer key lengths and mutual authentication.The introduction of AKA inside EAP allows several new applications.These include the following:o The use of the AKA also as a secure PPP authentication method indevices that already contain an identity module.o The use of the 3rd generation mobile network authenticationinfrastructure in the context of wireless LANso Relying on AKA and the existing infrastructure in a seamless waywith any other technology that can use EAP.AKA works in the following manner:o The identity module and the home environment have agreed on asecret key beforehand. (The "home environment" refers to the home operator’s authentication network infrastructure.)o The actual authentication process starts by having the homeenvironment produce an authentication vector, based on the secret key and a sequence number. The authentication vector contains arandom part RAND, an authenticator part AUTN used forauthenticating the network to the identity module, an expectedresult part XRES, a 128-bit session key for integrity check IK,and a 128-bit session key for encryption CK.Arkko & Haverinen Informational [Page 4]o The RAND and the AUTN are delivered to the identity module.o The identity module verifies the AUTN, again based on the secretkey and the sequence number. If this process is successful (theAUTN is valid and the sequence number used to generate AUTN iswithin the correct range), the identity module produces anauthentication result RES and sends it to the home environment.o The home environment verifies the correct result from the identity module. If the result is correct, IK and CK can be used toprotect further communications between the identity module and the home environment.When verifying AUTN, the identity module may detect that the sequence number the network uses is not within the correct range. In thiscase, the identity module calculates a sequence numbersynchronization parameter AUTS and sends it to the network. AKAauthentication may then be retried with a new authentication vectorgenerated using the synchronized sequence number.For a specification of the AKA mechanisms and how the cryptographicvalues AUTN, RES, IK, CK and AUTS are calculated, see [TS33.102] for UMTS and [S.S0055-A] for CDMA2000.In EAP-AKA, the EAP server node obtains the authentication vectors,compares RES and XRES, and uses CK and IK in key derivation.In the 3rd generation mobile networks, AKA is used for both radionetwork authentication and IP multimedia service authenticationpurposes. Different user identities and formats are used for these; the radio network uses the International Mobile Subscriber Identifier (IMSI), whereas the IP multimedia service uses the Network AccessIdentifier (NAI) [RFC4282].2. Terms and Conventions Used in This DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].The terms and abbreviations "authenticator", "backend authentication server", "EAP server", "peer", "Silently Discard", "Master SessionKey (MSK)", and "Extended Master Session Key (EMSK)" in this document are to be interpreted as described in [RFC3748].This document frequently uses the following terms and abbreviations. The AKA parameters are specified in detail in [TS33.102] for UMTS and [S.S0055-A] for CDMA2000.Arkko & Haverinen Informational [Page 5]AAA protocolAuthentication, Authorization and Accounting protocolAKAAuthentication and Key AgreementAuCAuthentication Centre. The mobile network element that canauthenticate subscribers in the mobile networks.AUTNAKA parameter. AUTN is an authentication value generated bythe AuC, which, together with the RAND, authenticates theserver to the peer, 128 bits.AUTSAKA parameter. A value generated by the peer uponexperiencing a synchronization failure, 112 bits.EAPExtensible Authentication Protocol [RFC3748]Fast Re-AuthenticationAn EAP-AKA authentication exchange that is based on keysderived upon a preceding full authentication exchange. The3rd Generation AKA is not used in the fast re-authenticationprocedure.Fast Re-Authentication IdentityA fast re-authentication identity of the peer, including anNAI realm portion in environments where a realm is used.Used on re-authentication only.Fast Re-Authentication UsernameThe username portion of fast re-authentication identity,i.e., not including any realm portions.Arkko & Haverinen Informational [Page 6]Full AuthenticationAn EAP-AKA authentication exchange that is based on the3rd Generation AKA procedure.GSMGlobal System for Mobile communications.NAINetwork Access Identifier [RFC4282]Identity ModuleIdentity module is used in this document to refer to thepart of the mobile device that contains authentication andkey agreement primitives. The identity module may be anintegral part of the mobile device or it may be an application on a smart card distributed by a mobile operator. USIM and(R)UIM are identity modules.NonceA value that is used at most once or that is never repeatedwithin the same cryptographic context. In general, a nonce can be predictable (e.g., a counter) or unpredictable (e.g., arandom value). Because some cryptographic properties maydepend on the randomness of the nonce, attention should be paid to whether a nonce is required to be random or not. In thisdocument, the term nonce is only used to denote random nonces, and it is not used to denote counters.Permanent IdentityThe permanent identity of the peer, including an NAI realmportion in environments where a realm is used. The permanentidentity is usually based on the IMSI. Used on fullauthentication only.Permanent UsernameThe username portion of permanent identity, i.e., not including any realm portions.Arkko & Haverinen Informational [Page 7]Pseudonym IdentityA pseudonym identity of the peer, including an NAI realmportion in environments where a realm is used. Used on fullauthentication only.Pseudonym UsernameThe username portion of pseudonym identity, i.e., not including any realm portions.RANDAn AKA parameter. Random number generated by the AuC,128 bits.RESAuthentication result from the peer, which, together withthe RAND, authenticates the peer to the server,128 bits.(R)UIMCDMA2000 (Removable) User Identity Module. (R)UIM is anapplication that is resident on devices such as smart cards,which may be fixed in the terminal or distributed by CDMA2000operators (when removable).SQNAn AKA parameter. Sequence number used in the authenticationprocess, 48 bits.SIMSubscriber Identity Module. The SIM is traditionally a smartcard distributed by a GSM operator.SRESThe authentication result parameter in GSM, corresponds tothe RES parameter in 3G AKA, 32 bits.Arkko & Haverinen Informational [Page 8]UAKUIM Authentication Key, used in CDMA2000 AKA. Both theidentity module and the network can optionally generate the UAK during the AKA computation in CDMA2000. UAK is not used inthis version of EAP-AKA.UIMPlease see (R)UIM.USIMUMTS Subscriber Identity Module. USIM is an application thatis resident on devices such as smart cards distributed by UMTS operators.3. Protocol OverviewFigure 1 shows the basic, successful full authentication exchange in EAP-AKA, when optional result indications are not used. Theauthenticator typically communicates with an EAP server that islocated on a backend authentication server using an AAA protocol.The authenticator shown in the figure is often simply relaying EAPmessages to and from the EAP server, but these backend AAAcommunications are not shown. At the minimum, EAP-AKA uses tworoundtrips to authenticate and authorize the peer and generatesession keys. As in other EAP schemes, an identity request/response message pair is usually exchanged first. On full authentication, the peer’s identity response includes either the user’s InternationalMobile Subscriber Identity (IMSI), or a temporary identity(pseudonym) if identity privacy is in effect, as specified inSection 4.1. (As specified in [RFC3748], the initial identityrequest is not required, and MAY be bypassed in cases where thenetwork can presume the identity, such as when using leased lines,dedicated dial-ups, etc. Please see Section 4.1.2 for specification of how to obtain the identity via EAP AKA messages.)After obtaining the subscriber identity, the EAP server obtains anauthentication vector (RAND, AUTN, RES, CK, IK) for use inauthenticating the subscriber. From the vector, the EAP serverderives the keying material, as specified in Section 6.4. The vector may be obtained by contacting an Authentication Centre (AuC) on themobile network; for example, per UMTS specifications, several vectors may be obtained at a time. Vectors may be stored in the EAP serverfor use at a later time, but they may not be reused.Arkko & Haverinen Informational [Page 9]In CDMA2000, the vector may include a sixth value called the UserIdentity Module Authentication Key (UAK). This key is not used inEAP-AKA.Next, the EAP server starts the actual AKA protocol by sending anEAP-Request/AKA-Challenge message. EAP-AKA packets encapsulateparameters in attributes, encoded in a Type, Length, Value format.The packet format and the use of attributes are specified inSection 8. The EAP-Request/AKA-Challenge message contains a RANDrandom number (AT_RAND), a network authentication token (AT_AUTN),and a message authentication code (AT_MAC). The EAP-Request/AKA-Challenge message MAY optionally contain encrypted data, which is used for identity privacy and fast re-authentication support, asdescribed in Section 4.1. The AT_MAC attribute contains a messageauthentication code covering the EAP packet. The encrypted data isnot shown in the figures of this section.The peer runs the AKA algorithm (typically using an identity module) and verifies the AUTN. If this is successful, the peer is talking to a legitimate EAP server and proceeds to send the EAP-Response/AKA-Challenge. This message contains a result parameter that allows the EAP server, in turn, to authenticate the peer, and the AT_MACattribute to integrity protect the EAP message.The EAP server verifies that the RES and the MAC in the EAP-Response/ AKA-Challenge packet are correct. Because protected successindications are not used in this example, the EAP server sends theEAP-Success packet, indicating that the authentication wassuccessful. (Protected success indications are discussed inSection 6.2.) The EAP server may also include derived keyingmaterial in the message it sends to the authenticator. The peer has derived the same keying material, so the authenticator does notforward the keying material to the peer along with EAP-Success.Arkko & Haverinen Informational [Page 10]Peer Authenticator| EAP-Request/Identity ||<------------------------------------------------------|| || EAP-Response/Identity || (Includes user’s NAI) ||------------------------------------------------------>|| +------------------------------+ | | Server runs AKA algorithms, | | | generates RAND and AUTN. | | +------------------------------+ | EAP-Request/AKA-Challenge || (AT_RAND, AT_AUTN, AT_MAC) ||<------------------------------------------------------|+-------------------------------------+ || Peer runs AKA algorithms, | || verifies AUTN and MAC, derives RES | || and session key | |+-------------------------------------+ || EAP-Response/AKA-Challenge || (AT_RES, AT_MAC) ||------------------------------------------------------>|| +--------------------------------+ | | Server checks the given RES, | | | and MAC and finds them correct.| | +--------------------------------+ | EAP-Success ||<------------------------------------------------------|Figure 1: EAP-AKA full authentication procedureArkko & Haverinen Informational [Page 11]Figure 2 shows how the EAP server rejects the Peer due to a failedauthentication.Peer Authenticator| EAP-Request/Identity ||<------------------------------------------------------|| || EAP-Response/Identity || (Includes user’s NAI) ||------------------------------------------------------>|| +------------------------------+ | | Server runs AKA algorithms, | | | generates RAND and AUTN. | | +------------------------------+ | EAP-Request/AKA-Challenge || (AT_RAND, AT_AUTN, AT_MAC) ||<------------------------------------------------------|+-------------------------------------+ || Peer runs AKA algorithms, | || possibly verifies AUTN, and sends an| || invalid response | |+-------------------------------------+ || EAP-Response/AKA-Challenge || (AT_RES, AT_MAC) ||------------------------------------------------------>|| +------------------------------------------+| | Server checks the given RES and the MAC, || | and finds one of them incorrect. || +------------------------------------------+| EAP-Request/AKA-Notification ||<------------------------------------------------------|| EAP-Response/AKA-Notification ||------------------------------------------------------>|| EAP-Failure ||<------------------------------------------------------|Figure 2: Peer authentication failsArkko & Haverinen Informational [Page 12]Figure 3 shows the peer rejecting the AUTN of the EAP server.The peer sends an explicit error message (EAP-Response/AKA-Authentication-Reject) to the EAP server, as usual in AKA whenAUTN is incorrect. This allows the EAP server to produce the sameerror statistics that AKA generally produces in UMTS or CDMA2000.Peer Authenticator| EAP-Request/Identity ||<------------------------------------------------------|| EAP-Response/Identity || (Includes user’s NAI) ||------------------------------------------------------>|| +------------------------------+ | | Server runs AKA algorithms, | | | generates RAND and a bad AUTN| | +------------------------------+ | EAP-Request/AKA-Challenge || (AT_RAND, AT_AUTN, AT_MAC) ||<------------------------------------------------------|+-------------------------------------+ || Peer runs AKA algorithms | || and discovers AUTN that can not be | || verified | |+-------------------------------------+ || EAP-Response/AKA-Authentication-Reject ||------------------------------------------------------>|| EAP-Failure ||<------------------------------------------------------|Figure 3: Network authentication failsThe AKA uses shared secrets between the Peer and the Peer’s homeoperator, together with a sequence number, to actually perform anauthentication. In certain circumstances, shown in Figure 4, it ispossible for the sequence numbers to get out of sequence.Arkko & Haverinen Informational [Page 13]Peer Authenticator| EAP-Request/Identity ||<------------------------------------------------------|| EAP-Response/Identity || (Includes user’s NAI) ||------------------------------------------------------>|| +------------------------------+ | | Server runs AKA algorithms, | | | generates RAND and AUTN. | | +------------------------------+ | EAP-Request/AKA-Challenge || (AT_RAND, AT_AUTN, AT_MAC) ||<------------------------------------------------------|+-------------------------------------+ || Peer runs AKA algorithms | || and discovers AUTN that contains an | || inappropriate sequence number | |+-------------------------------------+ || EAP-Response/AKA-Synchronization-Failure || (AT_AUTS) ||------------------------------------------------------>|| +---------------------------+| | Perform resynchronization || | Using AUTS and || | the sent RAND || +---------------------------+| |Figure 4: Sequence number synchronizationAfter the resynchronization process has taken place in the server and AAA side, the process continues by the server side sending a newEAP-Request/AKA-Challenge message.In addition to the full authentication scenarios described above,EAP-AKA includes a fast re-authentication procedure, which isspecified in Section 5. Fast re-authentication is based on keysderived on full authentication. If the peer has maintained stateinformation for re-authentication and wants to use fastre-authentication, then the peer indicates this by using a specificfast re-authentication identity instead of the permanent identity or a pseudonym identity.Arkko & Haverinen Informational [Page 14]4. Operation4.1. Identity Management4.1.1. Format, Generation, and Usage of Peer Identities4.1.1.1. GeneralIn the beginning of EAP authentication, the Authenticator or the EAP server usually issues the EAP-Request/Identity packet to the peer.The peer responds with EAP-Response/Identity, which contains theuser’s identity. The formats of these packets are specified in[RFC3748].Subscribers of mobile networks are identified with the International Mobile Subscriber Identity (IMSI) [TS23.003]. The IMSI is a stringof not more than 15 digits. It is composed of a Mobile Country Code (MCC) of 3 digits, a Mobile Network Code (MNC) of 2 or 3 digits, and a Mobile Subscriber Identification Number (MSIN) of not more than 10 digits. MCC and MNC uniquely identify the GSM operator and helpidentify the AuC from which the authentication vectors need to beretrieved for this subscriber.Internet AAA protocols identify users with the Network AccessIdentifier (NAI) [RFC4282]. When used in a roaming environment, the NAI is composed of a username and a realm, separated with "@"(username@realm). The username portion identifies the subscriberwithin the realm.This section specifies the peer identity format used in EAP-AKA. In this document, the term identity or peer identity refers to the whole identity string that is used to identify the peer. The peer identity may include a realm portion. "Username" refers to the portion of the peer identity that identifies the user, i.e., the username does notinclude the realm portion.4.1.1.2. Identity Privacy SupportEAP-AKA includes optional identity privacy (anonymity) support thatcan be used to hide the cleartext permanent identity and thereby make the subscriber’s EAP exchanges untraceable to eavesdroppers. Because the permanent identity never changes, revealing it would helpobservers to track the user. The permanent identity is usually based on the IMSI, which may further help the tracking, because the sameidentifier may be used in other contexts as well. Identity privacyis based on temporary identities, or pseudonyms, which are equivalent Arkko & Haverinen Informational [Page 15]to but separate from the Temporary Mobile Subscriber Identities(TMSI) that are used on cellular networks. Please see Section 12.1for security considerations regarding identity privacy.4.1.1.3. Username Types in EAP-AKA IdentitiesThere are three types of usernames in EAP-AKA peer identities:(1) Permanent usernames. For example,0123456789098765@ might be a valid permanent identity. In this example, 0123456789098765 is the permanent username.(2) Pseudonym usernames. For example, 2s7ah6n9q@ might be a valid pseudonym identity. In this example, 2s7ah6n9q is thepseudonym username.(3) Fast re-authentication usernames. For example,43953754@ might be a valid fast re-authenticationidentity. In this case, 43953754 is the fast re-authenticationusername. Unlike permanent usernames and pseudonym usernames, fastre-authentication usernames are one-time identifiers, which are notre-used across EAP exchanges.The first two types of identities are used only on fullauthentication, and the last type only on fast re-authentication.When the optional identity privacy support is not used, thenon-pseudonym permanent identity is used on full authentication. The fast re-authentication exchange is specified in Section 5.4.1.1.4. Username DecorationIn some environments, the peer may need to decorate the identity byprepending or appending the username with a string, in order toindicate supplementary AAA routing information in addition to the NAI realm. (The usage of an NAI realm portion is not considered to bedecoration.) Username decoration is out of the scope of thisdocument. However, it should be noted that username decoration might prevent the server from recognizing a valid username. Hence,although the peer MAY use username decoration in the identities that the peer includes in EAP-Response/Identity, and although the EAPserver MAY accept a decorated peer username in this message, the peer or the EAP server MUST NOT decorate any other peer identities thatare used in various EAP-AKA attributes. Only the identity used inEAP-Response/Identity may be decorated.Arkko & Haverinen Informational [Page 16]。

TCP常⽤⽹络和⽊马使⽤端⼝对照表，常⽤和不常⽤端⼝⼀览表【开始-运⾏- CMD ，输⼊ netstat -an 然后回车就可以查看端⼝】 端⼝：0 服务：Reserved 说明：通常⽤于分析操作系统。

这⼀⽅法能够⼯作是因为在⼀些系统中“0”是⽆效端⼝，当你试图使⽤通常的闭合端⼝连接它时将产⽣不同的结果。

⼀种典型的扫描，使⽤IP地址为0.0.0.0，设置ACK位并在以太⽹层⼴播。

端⼝：1 服务：tcpmux 说明：这显⽰有⼈在寻找SGI Irix机器。

Irix是实现tcpmux的主要提供者，默认情况下tcpmux在这种系统中被打开。

Irix机器在发布是含有⼏个默认的⽆密码的帐户，如：IP、GUEST UUCP、NUUCP、DEMOS 、TUTOR、DIAG、OUTOFBOX等 端⼝：7 服务：Echo 说明：能看到许多⼈搜索Fraggle放⼤器时，发送到X.X.X.0和X.X.X.255的信息。

端⼝：19 服务：Character Generator 说明：这是⼀种仅仅发送字符的服务。

UDP版本将会在收到UDP包后回应含有垃圾字符的包。

TCP连接时会发送含有垃圾字符的数据流直到连接关闭。

HACKER利⽤IP欺骗可以发动DoS攻击。

伪造两个chargen服务器之间的UDP包。

同样Fraggle 端⼝：21 服务：FTP 说明：FTP服务器所开放的端⼝，⽤于上传、下载。

最常见的攻击者⽤于寻找打开anonymous的FTP服务器的⽅法。

这些服务器带有可读写的⽬录。

⽊马Doly Trojan、Fore、Invisible FTP、WebEx、WinCrash和Blade Runner所开放的端⼝。

端⼝：22 服务：Ssh 说明：PcAnywhere建⽴的TCP和这⼀端⼝的连接可能是为了寻找ssh。

这⼀服务有许多弱点，如果配置成特定的模式，许多使⽤RSAREF库的版本就会有不少的漏洞存在。

端⼝：23 服务：Telnet 说明：远程登录，⼊侵者在搜索远程登录UNIX的服务。

File Transfer ProtocolFile Transfer Protocol (FTP) is a network protocol used to transfer data fromone computer to another through a network such as the Internet.FTP is a file transfer protocol for exchanging and manipulating files over a TCP computer network. A FTP client may connect to a FTP server to manipulate fileson that server. As there are many FTP client and server programs available for different operating systems, FTP is a popular choice for exchanging files independent of the operating systems involved.The TCP/IP model (RFC 1122)Application Layer BGP·DHCP·DNS·FTP·Gopher·GTP·HTTP·IMAP·IRC·NNTP·NTP·POP·RIP·RPC·RTCP·RTP·RTSP·SDP·SIP·SMTP·SNMP·SOAP·SSH·SSL·STUN·Telnet·TLS·XMPP·(more)Transport LayerTCP·UDP·DCCP·SCTP·RSVP·ECN·(more)Internet LayerIP (IPv4·IPv6) ·ICMP·ICMPv6·IGMP·IPsec·(more)Link Layer ARP·RARP·NDP·OSPF·Tunnels·Media Access Control·Device Drivers·(more)This box: view•talk•editConnection methodsFTP runs exclusively over TCP. It defaults to listen on port 21 for incoming connections from FTP clients. A connection to this port from the FTP Client forms the control stream on which commands are passed to the FTP server from theFTP client and on occasion from the FTP server to the FTP client. FTP uses out-of-band control, which means it uses a separate connection for control and data. Thus, for the actual file transfer to take place, a different connection is required which is called the data stream. Depending on the transfer mode, the process of setting up the data stream is different.In active mode, the FTP client opens a dynamic port, sends the FTP server the dynamic port number on which it is listening over the control stream and waits fora connection from the FTP server. When the FTP server initiates the data connection to the FTP client it binds the source port to port 20 on the FTP server.In order to use active mode, the client sends a PORT command, with the IP and port as argument. The format for the IP and port is "h1,h2,h3,h4,p1,p2". Eachfield is a decimal representation of 8 bits of the host IP, followed by the chosen data port. For example, a client with an IP of 192.168.0.1, listening on port 49154 for the data connection will send the command "PORT 192,168,0,1,192,2". The port fields should be interpreted as p1×256 + p2 = port, or, in this example,192×256 + 2 = 49154.In passive mode, the FTP server opens a dynamic port, sends the FTP client the server's IP address to connect to and the port on which it is listening (a 16-bit value broken into a high and low byte, as explained above) over the control stream and waits for a connection from the FTP client. In this case, the FTP client binds the source port of the connection to a dynamic port.To use passive mode, the client sends the PASV command to which the server would reply with something similar to "227 Entering Passive Mode(127,0,0,1,192,52)". The syntax of the IP address and port are the same as for the argument to the PORT command.In extended passive mode, the FTP server operates exactly the same as passive mode, however it only transmits the port number (not broken into high and low bytes) and the client is to assume that it connects to the same IP address that was originally connected to. Extended passive mode was added by RFC 2428 in September 1998.While data is being transferred via the data stream, the control stream sits idle. This can cause problems with large data transfers through firewalls which time out sessions after lengthy periods of idleness. While the file may well be successfully transferred, the control session can be disconnected by the firewall, causing an error to be generated.The FTP protocol supports resuming of interrupted downloads using the REST command. The client passes the number of bytes it has already received as argument to the REST command and restarts the transfer. In some commandline clients for example, there is an often-ignored but valuable command, "reget" (meaning "get again") that will cause an interrupted "get" command to be continued, hopefully to completion, after a communications interruption. Resuming uploads is not as easy. Although the FTP protocol supports the APPE command to append data to a file on the server, the client does not know the exact position at which a transfer got interrupted. It has to obtain the size of the file some other way, for example over a directory listing or using the SIZE command.In ASCII mode (see below), resuming transfers can be troublesome if client and server use different end of line characters.The objectives of FTP, as outlined by its RFC, are:1. To promote sharing of files (computer programs and/or data).2. To encourage indirect or implicit use of remote computers.3. To shield a user from variations in file storage systems among differenthosts.4. To transfer data reliably, and efficiently.Criticisms of FTP•Passwords and file contents are sent in clear text, which can be intercepted by eavesdroppers. There are protocol enhancements thatremedy this, for instance by using SSL, TLS or Kerberos.•Multiple TCP/IP connections are used, one for the control connection, and one for each download, upload, or directory listing. Firewalls may needadditional logic and/or configuration changes to account for theseconnections.•It is hard to filter active mode FTP traffic on the client side by using a firewall, since the client must open an arbitrary port in order to receive the connection. This problem is largely resolved by using passive mode FTP.•It is possible to abuse the protocol's built-in proxy features to tell a server to send data to an arbitrary port of a third computer; see FXP.•FTP is a high latency protocol due to the number of commands needed to initiate a transfer.•No integrity check on the receiver side. If a transfer is interrupted, the receiver has no way to know if the received file is complete or not. Someservers support extensions to calculate for example a file's MD5 sum (e.g.using the SITE MD5 command), XCRC, XMD5, XSHA or CRC checksum, however even then the client has to make explicit use of them. In theabsence of such extensions, integrity checks have to be managedexternally.•No date/timestamp attribute transfer. Uploaded files are given a new current timestamp, unlike other file transfer protocols such as SFTP, which allow attributes to be included. There is no way in the standard FTPprotocol to set the time-last-modified (or time-created) datestamp thatmost modern filesystems preserve. There is a draft of a proposedextension that adds new commands for this, but as of yet, most of thepopular FTP servers do not support it.Security problemsThe original FTP specification is an inherently insecure method of transferring files because there is no method specified for transferring data in an encrypted fashion. This means that under most network configurations, user names, passwords, FTP commands and transferred files can be "sniffed" or viewed by anyone on the same network using a packet sniffer. This is a problem common to many Internet protocol specifications written prior to the creation of SSL such asHTTP, SMTP and Telnet. The common solution to this problem is to use either SFTP (SSH File Transfer Protocol), or FTPS (FTP over SSL), which adds SSL or TLS encryption to FTP as specified in RFC 4217.FTP return codesMain article: List of FTP server return codesFTP server return codes indicate their status by the digits within them. A brief explanation of various digits' meanings are given below:•1xx: Positive Preliminary reply. The action requested is being initiated but there will be another reply before it begins.•2xx: Positive Completion reply. The action requested has been completed.The client may now issue a new command.•3xx: Positive Intermediate reply. The command was successful, but a further command is required before the server can act upon the request.•4xx: Transient Negative Completion reply. The command was not successful, but the client is free to try the command again as the failure is only temporary.•5xx: Permanent Negative Completion reply. The command was not successful and the client should not attempt to repeat it again.•x0x: The failure was due to a syntax error.•x1x: This response is a reply to a request for information.•x2x: This response is a reply relating to connection information.•x3x: This response is a reply relating to accounting and authorization.•x4x: Unspecified as yet•x5x: These responses indicate the status of the Server file system vis-a-vis the requested transfer or other file system action.Anonymous FTPA host which provides an FTP service may additionally provide Anonymous FTP access as well. Under this arrangement, users do not strictly need an account on the host. Instead the user typically enters 'anonymous' or 'ftp' when prompted for username. Although users are commonly asked to send their email address as their password, little to no verification is actually performed on the supplied data.As modern FTP clients typically hide the anonymous login process from the user, the ftp client will supply dummy data as the password (since the user's email address may not be known to the application). For example, the following ftp user agents specify the listed passwords for anonymous logins:•Mozilla Firefox (2.0) — mozilla@•KDE Konqueror (3.5) — anonymous@•wget (1.10.2) — -wget@•lftp (3.4.4) — lftp@The Gopher protocol has been suggested as an alternative to anonymous FTP, as well as Trivial File Transfer Protocol and File Service Protocol.[citation needed] Data formatWhile transferring data over the network, several data representations can be used. The two most common transfer modes are:1. ASCII mode2. Binary mode: In "Binary mode", the sending machine sends each file bytefor byte and as such the recipient stores the bytestream as it receives it.(The FTP standard calls this "IMAGE" or "I" mode)In "ASCII mode", any form of data that is not plain text will be corrupted. When a file is sent using an ASCII-type transfer, the individual letters, numbers, and characters are sent using their ASCII character codes. The receiving machine saves these in a text file in the appropriate format (for example, a Unix machine saves it in a Unix format, a Windows machine saves it in a Windows format). Hence if an ASCII transfer is used it can be assumed plain text is sent, which is stored by the receiving computer in its own format. Translating between text formats might entail substituting the end of line and end of file characters used on the source platform with those on the destination platform, e.g. a Windows machine receiving a file from a Unix machine will replace the line feeds with carriage return-line feed pairs. It might also involve translating characters; for example, when transferring from an IBM mainframe to a system using ASCII, EBCDIC characters used on the mainframe will be translated to their ASCII equivalents, and when transferring from the system using ASCII to the mainframe, ASCII characters will be translated to their EBCDIC equivalents.By default, most FTP clients use ASCII mode. Some clients try to determine the required transfer-mode by inspecting the file's name or contents, or by determining whether the server is running an operating system with the same text file format.The FTP specifications also list the following transfer modes:1. EBCDIC mode - this transfers bytes, except they are encoded in EBCDICrather than ASCII. Thus, for example, the ASCII mode server2. Local mode - this is designed for use with systems that are word-orientedrather than byte-oriented. For example mode "L 36" can be used totransfer binary data between two 36-bit machines. In L mode, the wordsare packed into bytes rather than being padded. Given the predominanceof byte-oriented hardware nowadays, this mode is rarely used. However,some FTP servers accept "L 8" as being equivalent to "I".In practice, these additional transfer modes are rarely used. They are however still used by some legacy mainframe systems.The text (ASCII/EBCDIC) modes can also be qualified with the type of carriage control used (e.g. TELNET NVT carriage control, ASA carriage control), although that is rarely used nowadays.Note that the terminology "mode" is technically incorrect, although commonly used by FTP clients. "MODE" in RFC 959 refers to the format of the protocol data stream (STREAM, BLOCK or COMPRESSED), as opposed to the format of the underlying file. What is commonly called "mode" is actually the "TYPE", which specifies the format of the file rather than the data stream. FTP also supports specification of the file structure ("STRU"), which can be either FILE (stream-oriented files), RECORD (record-oriented files) or PAGE (special type designed for use with TENEX). PAGE STRU is not really useful for non-TENEX systems, and RFC1123 section 4.1.2.3 recommends that it not be implemented.FTP and web browsersMost recent web browsers and file managers can connect to FTP servers, although they may lack the support for protocol extensions such as FTPS. This allows manipulation of remote files over FTP through an interface similar to that used for local files. This is done via an FTP URL, which takes the formftp(s)://<ftpserveraddress> (e.g., ftp:///). A password can optionally be given in the URL, e.g.:ftp(s)://<login>:<password>@<ftpserveraddress>:<port>. Most web-browsers require the use of passive mode FTP, which not all FTP servers are capable of handling. Some browsers allow only the downloading of files, but offer no way to upload files to the server.FTP and NAT devicesThe representation of the IPs and ports in the PORT command and PASV reply poses another challenge for NAT devices in handling FTP. The NAT device must alter these values, so that they contain the IP of the NAT-ed client, and a port chosen by the NAT device for the data connection. The new IP and port will probably differ in length in their decimal representation from the original IP and port. This means that altering the values on the control connection by the NAT device must be done carefully, changing the TCP Sequence and Acknowledgment fields for all subsequent packets.For example: A client with an IP of 192.168.0.1, starting an active mode transfer on port 1025, will send the string "PORT 192,168,0,1,4,1". A NAT device masquerading this client with an IP of 192.168.15.5, with a chosen port of 2000 for the data connection, will need to replace the above string with "PORT192,168,15,5,7,208".The new string is 23 characters long, compared to 20 characters in the original packet. The Acknowledgment field by the server to this packet will need to be decreased by 3 bytes by the NAT device for the client to correctly understand that the PORT command has arrived to the server. If the NAT device is not capable of correcting the Sequence and Acknowledgement fields, it will not be possible to use active mode FTP. Passive mode FTP will work in this case, because the information about the IP and port for the data connection is sent by the server, which doesn't need to be NATed. If NAT is performed on the server by the NAT device, then the exact opposite will happen. Active mode will work, but passive mode will fail.It should be noted that many NAT devices perform this protocol inspection and modify the PORT command without being explicitly told to do so by the user. This can lead to several problems. First of all, there is no guarantee that the used protocol really is FTP, or it might use some extension not understood by the NAT device. One example would be an SSL secured FTP connection. Due to the encryption, the NAT device will be unable to modify the address. As result, active mode transfers will fail only if encryption is used, much to the confusion of the user.The proper way to solve this is to tell the client which IP address and ports to use for active mode. Furthermore, the NAT device has to be configured to forward the selected range of ports to the client's machine.See also Application-level gatewayFTP over SSH (SFTP)FTP over SSH (SFTP) refers to the practice of tunneling a normal FTP session over an SSH connection.Because FTP uses multiple TCP connections (unusual for a TCP/IP protocol that is still in use), it is particularly difficult to tunnel over SSH. With many SSH clients, attempting to set up a tunnel for the control channel (the initial client-to-server connection on port 21) will protect only that channel; when data is transferred, the FTP software at either end will set up new TCP connections (data channels) which will bypass the SSH connection, and thus have no confidentiality, integrity protection, etc.If the FTP client is configured to use passive mode and to connect to a SOCKS server interface that many SSH clients can present for tunneling, it is possible to run all the FTP channels over the SSH connection.Otherwise, it is necessary for the SSH client software to have specific knowledge of the FTP protocol, and monitor and rewrite FTP control channel messages and autonomously open new forwardings for FTP data channels. Version 3 of SSH Communications Security's software suite, and the GPL licensed FONC are two software packages that support this mode.FTP over SSH is sometimes referred to as secure FTP; this should not be confused with other methods of securing FTP, such as with SSL/TLS (FTPS). Other methods of transferring files using SSH that are not related to FTP include SFTP and SCP; in each of these, the entire conversation (credentials and data) is always protected by the SSH protocol.See also•FTAM•FTPFS•List of FTP server return codes•List of FTP commands•List of file transfer protocols•OBEX•Shared file access•TCP Wrapper•Comparison of FTP client software•List of FTP server software•Comparison of FTP server softwareFurther readingThe protocol is standardized in RFC 959 by the IETF as:•RFC 959 File Transfer Protocol (FTP). J. Postel, J. Reynolds. Oct-1985.This obsoleted the preceding RFC 765 and earlier FTP RFCs back to the original RFC 114.•RFC 1579 Firewall-Friendly FTP.•RFC 2228 — FTP Security Extensions•RFC 2428 — Extensions for IPv6, NAT, and Extended passive mode Sep-1998.•RFC 3659 — Extensions to FTP. P. Hethmon. March-2007. External links•FTP Reviewed — a review of the protocol notably from a security standpoint•Raw FTP command list•FTP Sequence Diagram (in PDF format)Retrieved from "/wiki/File_Transfer_Protocol"。

Network Working Group D. Farinacci Request for Comments: 2784 T. Li Category: Standards Track Procket NetworksS. HanksEnron CommunicationsD. MeyerCisco SystemsP. TrainaJuniper NetworksMarch 2000Generic Routing Encapsulation (GRE)Status of this MemoThis document specifies an Internet standards track protocol for theInternet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2000). All Rights Reserved.AbstractThis document specifies a protocol for encapsulation of an arbitrarynetwork layer protocol over another arbitrary network layer protocol.1. IntroductionA number of different proposals [RFC1234, RFC1226] currently existfor the encapsulation of one protocol over another protocol. Othertypes of encapsulations [RFC1241, RFC1479] have been proposed fortransporting IP over IP for policy purposes. This memo describes aprotocol which is very similar to, but is more general than, theabove proposals. In attempting to be more general, many protocolspecific nuances have been ignored. The result is that this proposalmay be less suitable for a situation where a specific "X over Y"encapsulation has been described. It is the attempt of this protocolto provide a simple, general purpose mechanism which reduces theproblem of encapsulation from its current O(n^2) size to a moremanageable size. This memo purposely does not address the issue ofwhen a packet should be encapsulated. This memo acknowledges, butdoes not address problems such as mutual encapsulation [RFC1326]. Farinacci, et al. Standards Track [Page 1]RFC 2784 Generic Routing Encapsulation March 2000In the most general case, a system has a packet that needs to beencapsulated and delivered to some destination. We will call thisthe payload packet. The payload is first encapsulated in a GREpacket. The resulting GRE packet can then be encapsulated in someother protocol and then forwarded. We will call this outer protocolthe delivery protocol. The algorithms for processing this packet arediscussed later.Finally this specification describes the intersection of GREcurrently deployed by multiple vendors.The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as definedin RFC 2119 [RFC2119].2. Structure of a GRE Encapsulated PacketA GRE encapsulated packet has the form:---------------------------------| || Delivery Header || |---------------------------------| || GRE Header || |---------------------------------| || Payload packet || |---------------------------------This specification is generally concerned with the structure of theGRE header, although special consideration is given to some of theissues surrounding IPv4 payloads.2.1. GRE HeaderThe GRE packet header has the form: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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Farinacci, et al. Standards Track [Page 2]RFC 2784 Generic Routing Encapsulation March 2000 2.2. Checksum Present (bit 0)If the Checksum Present bit is set to one, then the Checksum and theReserved1 fields are present and the Checksum field contains validinformation. Note that a compliant implementation MUST accept andprocess this field.2.3. Reserved0 (bits 1-12)A receiver MUST discard a packet where any of bits 1-5 are non-zero,unless that receiver implements RFC 1701. Bits 6-12 are reserved forfuture use. These bits MUST be sent as zero and MUST be ignored onreceipt.2.3.1. Version Number (bits 13-15)The Version Number field MUST contain the value zero.2.4. Protocol Type (2 octets)The Protocol Type field contains the protocol type of the payloadpacket. These Protocol Types are defined in [RFC1700] as "ETHERTYPES" and in [ETYPES]. An implementation receiving a packetcontaining a Protocol Type which is not listed in [RFC1700] or[ETYPES] SHOULD discard the packet.2.5. Checksum (2 octets)The Checksum field contains the IP (one's complement) checksum sum ofthe all the 16 bit words in the GRE header and the payload packet.For purposes of computing the checksum, the value of the checksumfield is zero. This field is present only if the Checksum Present bitis set to one.2.6. Reserved1 (2 octets)The Reserved1 field is reserved for future use, and if present, MUSTbe transmitted as zero. The Reserved1 field is present only when theChecksum field is present (that is, Checksum Present bit is set toone).3. IPv4 as a PayloadWhen IPv4 is being carried as the GRE payload, the Protocol Typefield MUST be set to 0x800.Farinacci, et al. Standards Track [Page 3]RFC 2784 Generic Routing Encapsulation March 2000 3.1. Forwarding Decapsulated IPv4 Payload PacketsWhen a tunnel endpoint decapsulates a GRE packet which has an IPv4packet as the payload, the destination address in the IPv4 payloadpacket header MUST be used to forward the packet and the TTL of thepayload packet MUST be decremented. Care should be taken whenforwarding such a packet, since if the destination address of thepayload packet is the encapsulator of the packet (i.e., the other endof the tunnel), looping can occur. In this case, the packet MUST bediscarded.4. IPv4 as a Delivery ProtocolThe IPv4 protocol 47 [RFC1700] is used when GRE packets areenapsulated in IPv4. See [RFC1122] for requirements relating to thedelivery of packets over IPv4 networks.5. Interoperation with RFC 1701 Compliant ImplementationsIn RFC 1701, the field described here as Reserved0 contained a numberof flag bits which this specification deprecates. In particular, theRouting Present, Key Present, Sequence Number Present, and StrictSource Route bits have been deprecated, along with the RecursionControl field. As a result, the GRE header will never contain theKey, Sequence Number or Routing fields specified in RFC 1701.There are, however, existing implementations of RFC 1701. Thefollowing sections describe correct interoperation with suchimplementations.5.1. RFC 1701 Compliant ReceiverAn implementation complying to this specification will transmit theReserved0 field set to zero. An RFC 1701 compliant receiver willinterpret this as having the Routing Present, Key Present, SequenceNumber Present, and Strict Source Route bits set to zero, and willnot expect the RFC 1701 Key, Sequence Number or Routing fields to bepresent.5.2. RFC 1701 Compliant TransmitterAn RFC 1701 transmitter may set any of the Routing Present, KeyPresent, Sequence Number Present, and Strict Source Route bits set toone, and thus may transmit the RFC 1701 Key, Sequence Number orRouting fields in the GRE header. As stated in Section 5.3, a packetwith non-zero bits in any of bits 1-5 MUST be discarded unless thereceiver implements RFC 1701.Farinacci, et al. Standards Track [Page 4]RFC 2784 Generic Routing Encapsulation March 2000 6. Security ConsiderationsSecurity in a network using GRE should be relatively similar tosecurity in a normal IPv4 network, as routing using GRE follows thesame routing that IPv4 uses natively. Route filtering will remainunchanged. However packet filtering requires either that a firewalllook inside the GRE packet or that the filtering is done on the GREtunnel endpoints. In those environments in which this is consideredto be a security issue it may be desirable to terminate the tunnel atthe firewall.7. IANA ConsiderationsThis section considers the assignment of additional GRE V ersionNumbers and Protocol Types.7.1. GRE Version NumbersThis document specifies GRE version number 0. GRE version number 1 isused by PPTP [RFC2637]. Additional GRE version numbers are assignedby IETF Consensus as defined in RFC 2434 [RFC2434].7.2. Protocol TypesGRE uses an ETHER Type for the Protocol Type. New ETHER TYPES areassigned by Xerox Systems Institute [RFC1700].8. AcknowledgmentsThis document is derived from the original ideas of the authors ofRFC 1701 and RFC 1702. Hitoshi Asaeda, Scott Bradner, Randy Bush,Brian Carpenter, Bill Fenner, Andy Malis, Thomas Narten, Dave Thaler,Tim Gleeson and others provided many constructive and insightfulcomments.Farinacci, et al. Standards Track [Page 5]RFC 2784 Generic Routing Encapsulation March 2000 9. Appendix -- Known IssuesThis document specifies the behavior of currently deployed GREimplementations. As such, it does not attempt to address thefollowing known issues:o Interaction Path MTU Discovery (PMTU) [RFC1191]Existing implementations of GRE, when using IPv4 as the DeliveryHeader, do not implement Path MTU discovery and do not set theDon't Fragment bit in the Delivery Header. This can cause largepackets to become fragmented within the tunnel and reassembled atthe tunnel exit (independent of whether the payload packet is usingPMTU). If a tunnel entry point were to use Path MTU discovery,however, that tunnel entry point would also need to relay ICMPunreachable error messages (in particular the "fragmentation neededand DF set" code) back to the originator of the packet, which isnot a requirement in this specification. Failure to properly relayPath MTU information to an originator can result in the followingbehavior: the originator sets the don't fragment bit, the packetgets dropped within the tunnel, but since the originator doesn'treceive proper feedback, it retransmits with the same PMTU, causingsubsequently transmitted packets to be dropped.o IPv6 as Delivery and/or Payload ProtocolThis specification describes the intersection of GRE currentlydeployed by multiple vendors. IPv6 as delivery and/or payloadprotocol is not included in the currently deployed versions of GRE.o Interaction with ICMPo Interaction with the Differentiated Services Architectureo Multiple and Looping Encapsulations10. REFERENCES[ETYPES] ftp:///in-notes/iana/assignments/ethernet-numbers[RFC1122] Braden, R., "Requirements for Internet hosts -communication layers", STD 3, RFC 1122, October 1989.[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.Farinacci, et al. Standards Track [Page 6]RFC 2784 Generic Routing Encapsulation March 2000[RFC1226] Kantor, B., "Internet Protocol Encapsulation of AX.25Frames", RFC 1226, May 1991.[RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks",RFC 1234, June 1991.[RFC1241] Woodburn, R. and D. Mills, "Scheme for an InternetEncapsulation Protocol: Version 1", RFC 1241, July 1991.[RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered Dangerous",RFC 1326, May 1992.[RFC1479] Steenstrup, M., "Inter-Domain Policy Routing ProtocolSpecification: Version 1", RFC 1479, July 1993.[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC1700, October 1994.[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "GenericRouting Encapsulation", RFC 1701, October 1994.[RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "GenericRouting Encapsulation over IPv4 networks", RFC 1702,October 1994.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March, 1997.[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner,"Internet Security Association and Key Management Protocol(ISAKMP)", RFC 2408, November 1998.[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing anIANA Considerations Section in RFCs", BCP 26, RFC 2434,October, 1998.[RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol(PPTP)", RFC 2637, July, 1999.Farinacci, et al. Standards Track [Page 7]RFC 2784 Generic Routing Encapsulation March 2000 11. Authors' AddressesDino FarinacciProcket Networks3850 No. First St., Ste. CSan Jose, CA 95134EMail: dino@Tony LiProcket Networks3850 No. First St., Ste. CSan Jose, CA 95134Phone: +1 408 954 7903Fax: +1 408 987 6166EMail: tony1@Stan HanksEnron CommunicationsEMail: stan_hanks@David MeyerCisco Systems, Inc.170 Tasman DriveSan Jose, CA, 95134EMail: dmm@Paul TrainaJuniper NetworksEMail: pst@Farinacci, et al. Standards Track [Page 8]RFC 2784 Generic Routing Encapsulation March 200012. Full Copyright StatementCopyright (C) The Internet Society (2000). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain itor assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph areincluded on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Farinacci, et al. Standards Track [Page 9]。

Internet Engineering Task Force (IETF) H. Krawczyk Request for Comments: 5869 IBM Research Category: Informational P. Eronen ISSN: 2070-1721 Nokia May 2010 HMAC-based Extract-and-Expand Key Derivation Function (HKDF)AbstractThis document specifies a simple Hashed Message Authentication Code(HMAC)-based key derivation function (HKDF), which can be used as abuilding block in various protocols and applications. The keyderivation function (KDF) is intended to support a wide range ofapplications and requirements, and is conservative in its use ofcryptographic hash functions.Status of This MemoThis document is not an Internet Standards Track specification; it is published for informational purposes.This document is a product of the Internet Engineering Task Force(IETF). It represents the consensus of the IETF community. It hasreceived public review and has been approved for publication by theInternet Engineering Steering Group (IESG). Not all documentsapproved by the IESG are a candidate for any level of InternetStandard; see Section 2 of RFC 5741.Information about the current status of this document, any errata,and how to provide feedback on it may be obtained at/info/rfc5869.Copyright NoticeCopyright (c) 2010 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e ofthe Trust Legal Provisions and are provided without warranty asdescribed in the Simplified BSD License.Krawczyk & Eronen Informational [Page 1]1. IntroductionA key derivation function (KDF) is a basic and essential component of cryptographic systems. Its goal is to take some source of initialkeying material and derive from it one or more cryptographicallystrong secret keys.This document specifies a simple HMAC-based [HMAC] KDF, named HKDF,which can be used as a building block in various protocols andapplications, and is already used in several IETF protocols,including [IKEv2], [PANA], and [EAP-AKA]. The purpose is to document this KDF in a general way to facilitate adoption in future protocols and applications, and to discourage the proliferation of multiple KDF mechanisms. It is not intended as a call to change existingprotocols and does not change or update existing specifications using this KDF.HKDF follows the "extract-then-expand" paradigm, where the KDFlogically consists of two modules. The first stage takes the inputkeying material and "extracts" from it a fixed-length pseudorandomkey K. The second stage "expands" the key K into several additional pseudorandom keys (the output of the KDF).In many applications, the input keying material is not necessarilydistributed uniformly, and the attacker may have some partialknowledge about it (for example, a Diffie-Hellman value computed by a key exchange protocol) or even partial control of it (as in someentropy-gathering applications). Thus, the goal of the "extract"stage is to "concentrate" the possibly dispersed entropy of the input keying material into a short, but cryptographically strong,pseudorandom key. In some applications, the input may already be agood pseudorandom key; in these cases, the "extract" stage is notnecessary, and the "expand" part can be used alone.The second stage "expands" the pseudorandom key to the desiredlength; the number and lengths of the output keys depend on thespecific cryptographic algorithms for which the keys are needed.Note that some existing KDF specifications, such as NIST SpecialPublication 800-56A [800-56A], NIST Special Publication 800-108[800-108] and IEEE Standard 1363a-2004 [1363a], either only consider the second stage (expanding a pseudorandom key), or do not explicitly differentiate between the "extract" and "expand" stages, oftenresulting in design shortcomings. The goal of this specification is to accommodate a wide range of KDF requirements while minimizing the assumptions about the underlying hash function. The "extract-then-expand" paradigm supports well this goal (see [HKDF-paper] for moreinformation about the design rationale).Krawczyk & Eronen Informational [Page 2]2. HMAC-based Key Derivation Function (HKDF)2.1. NotationHMAC-Hash denotes the HMAC function [HMAC] instantiated with hashfunction ’Hash’. HMAC always has two arguments: the first is a keyand the second an input (or message). (Note that in the extractstep, ’IKM’ is used as the HMAC input, not as the HMAC key.)When the message is composed of several elements we use concatenation (denoted |) in the second argument; for example, HMAC(K, elem1 |elem2 | elem3).The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].2.2. Step 1: ExtractHKDF-Extract(salt, IKM) -> PRKOptions:Hash a hash function; HashLen denotes the length of thehash function output in octetsInputs:salt optional salt value (a non-secret random value);if not provided, it is set to a string of HashLen zeros. IKM input keying materialOutput:PRK a pseudorandom key (of HashLen octets)The output PRK is calculated as follows:PRK = HMAC-Hash(salt, IKM)2.3. Step 2: ExpandHKDF-Expand(PRK, info, L) -> OKMOptions:Hash a hash function; HashLen denotes the length of thehash function output in octetsKrawczyk & Eronen Informational [Page 3]Inputs:PRK a pseudorandom key of at least HashLen octets(usually, the output from the extract step)info optional context and application specific information(can be a zero-length string)L length of output keying material in octets(<= 255*HashLen)Output:OKM output keying material (of L octets)The output OKM is calculated as follows:N = ceil(L/HashLen)T = T(1) | T(2) | T(3) | ... | T(N)OKM = first L octets of Twhere:T(0) = empty string (zero length)T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)...(where the constant concatenated to the end of each T(n) is asingle octet.)3. Notes to HKDF UsersThis section contains a set of guiding principles regarding the useof HKDF. A much more extensive account of such principles and design rationale can be found in [HKDF-paper].3.1. To Salt or not to SaltHKDF is defined to operate with and without random salt. This isdone to accommodate applications where a salt value is not available. We stress, however, that the use of salt adds significantly to thestrength of HKDF, ensuring independence between different uses of the hash function, supporting "source-independent" extraction, andstrengthening the analytical results that back the HKDF design.Random salt differs fundamentally from the initial keying material in two ways: it is non-secret and can be re-used. As such, salt values are available to many applications. For example, a pseudorandomnumber generator (PRNG) that continuously produces outputs byapplying HKDF to renewable pools of entropy (e.g., sampled systemevents) can fix a salt value and use it for multiple applications of Krawczyk & Eronen Informational [Page 4]HKDF without having to protect the secrecy of the salt. In adifferent application domain, a key agreement protocol derivingcryptographic keys from a Diffie-Hellman exchange can derive a saltvalue from public nonces exchanged and authenticated betweencommunicating parties as part of the key agreement (this is theapproach taken in [IKEv2]).Ideally, the salt value is a random (or pseudorandom) string of thelength HashLen. Yet, even a salt value of less quality (shorter insize or with limited entropy) may still make a significantcontribution to the security of the output keying material; designers of applications are therefore encouraged to provide salt values toHKDF if such values can be obtained by the application.It is worth noting that, while not the typical case, someapplications may even have a secret salt value available for use; in such a case, HKDF provides an even stronger security guarantee. Anexample of such application is IKEv1 in its "public-key encryptionmode", where the "salt" to the extractor is computed from nonces that are secret; similarly, the pre-shared mode of IKEv1 uses a secretsalt derived from the pre-shared key.3.2. The ’info’ Input to HKDFWhile the ’info’ value is optional in the definition of HKDF, it isoften of great importance in applications. Its main objective is to bind the derived key material to application- and context-specificinformation. For example, ’info’ may contain a protocol number,algorithm identifiers, user identities, etc. In particular, it mayprevent the derivation of the same keying material for differentcontexts (when the same input key material (IKM) is used in suchdifferent contexts). It may also accommodate additional inputs tothe key expansion part, if so desired (e.g., an application may want to bind the key material to its length L, thus making L part of the’info’ field). There is one technical requirement from ’info’: itshould be independent of the input key material value IKM.3.3. To Skip or not to SkipIn some applications, the input key material IKM may already bepresent as a cryptographically strong key (for example, the premaster secret in TLS RSA cipher suites would be a pseudorandom string,except for the first two octets). In this case, one can skip theextract part and use IKM directly to key HMAC in the expand step. On the other hand, applications may still use the extract part for thesake of compatibility with the general case. In particular, if IKMis random (or pseudorandom) but longer than an HMAC key, the extract step can serve to output a suitable HMAC key (in the case of HMAC Krawczyk & Eronen Informational [Page 5]this shortening via the extractor is not strictly necessary sinceHMAC is defined to work with long keys too). Note, however, that if the IKM is a Diffie-Hellman value, as in the case of TLS with Diffie- Hellman, then the extract part SHOULD NOT be skipped. Doing so would result in using the Diffie-Hellman value g^{xy} itself (which is NOT a uniformly random or pseudorandom string) as the key PRK for HMAC.Instead, HKDF should apply the extract step to g^{xy} (preferablywith a salt value) and use the resultant PRK as a key to HMAC in the expansion part.In the case where the amount of required key bits, L, is no more than HashLen, one could use PRK directly as the OKM. This, however, isNOT RECOMMENDED, especially because it would omit the use of ’info’as part of the derivation process (and adding ’info’ as an input tothe extract step is not advisable -- see [HKDF-paper]).3.4. The Role of IndependenceThe analysis of key derivation functions assumes that the inputkeying material (IKM) comes from some source modeled as a probability distribution over bit streams of a certain length (e.g., streamsproduced by an entropy pool, values derived from Diffie-Hellmanexponents chosen at random, etc.); each instance of IKM is a samplefrom that distribution. A major goal of key derivation functions is to ensure that, when applying the KDF to any two values IKM and IKM’ sampled from the (same) source distribution, the resultant keys OKMand OKM’ are essentially independent of each other (in a statistical or computational sense). To achieve this goal, it is important that inputs to KDF are selected from appropriate input distributions andalso that inputs are chosen independently of each other (technically, it is necessary that each sample will have sufficient entropy, evenwhen conditioned on other inputs to KDF).Independence is also an important aspect of the salt value providedto a KDF. While there is no need to keep the salt secret, and thesame salt value can be used with multiple IKM values, it is assumedthat salt values are independent of the input keying material. Inparticular, an application needs to make sure that salt values arenot chosen or manipulated by an attacker. As an example, considerthe case (as in IKE) where the salt is derived from nonces suppliedby the parties in a key exchange protocol. Before the protocol canuse such salt to derive keys, it needs to make sure that these nonces are authenticated as coming from the legitimate parties rather thanselected by the attacker (in IKE, for example this authentication is an integral part of the authenticated Diffie-Hellman exchange). Krawczyk & Eronen Informational [Page 6]4. Applications of HKDFHKDF is intended for use in a wide variety of KDF applications.These include the building of pseudorandom generators from imperfect sources of randomness (such as a physical random number generator(RNG)); the generation of pseudorandomness out of weak sources ofrandomness, such as entropy collected from system events, user’skeystrokes, etc.; the derivation of cryptographic keys from a shared Diffie-Hellman value in a key-agreement protocol; derivation ofsymmetric keys from a hybrid public-key encryption scheme; keyderivation for key-wrapping mechanisms; and more. All of theseapplications can benefit from the simplicity and multi-purpose nature of HKDF, as well as from its analytical foundation.On the other hand, it is anticipated that some applications will not be able to use HKDF "as-is" due to specific operational requirements, or will be able to use it but without the full benefits of thescheme. One significant example is the derivation of cryptographickeys from a source of low entropy, such as a user’s password. Theextract step in HKDF can concentrate existing entropy but cannotamplify entropy. In the case of password-based KDFs, a main goal is to slow down dictionary attacks using two ingredients: a salt value, and the intentional slowing of the key derivation computation. HKDF naturally accommodates the use of salt; however, a slowing downmechanism is not part of this specification. Applications interested in a password-based KDF should consider whether, for example, [PKCS5] meets their needs better than HKDF.5. Security ConsiderationsIn spite of the simplicity of HKDF, there are many securityconsiderations that have been taken into account in the design andanalysis of this construction. An exposition of all of these aspects is beyond the scope of this document. Please refer to [HKDF-paper]for detailed information, including rationale for the design and for the guidelines presented in Section 3.A major effort has been made in the above paper [HKDF-paper] toprovide a cryptographic analysis of HKDF as a multi-purpose KDF that exercises much care in the way it utilizes cryptographic hashfunctions. This is particularly important due to the limitedconfidence we have in the strength of current hash functions. Thisanalysis, however, does not imply the absolute security of anyscheme, and it depends heavily on the strength of the underlying hash function and on modeling choices. Yet, it serves as a strongindication of the correct structure of the HKDF design and itsadvantages over other common KDF schemes.Krawczyk & Eronen Informational [Page 7]6. AcknowledgmentsThe authors would like to thank members of the CFRG (Crypto ForumResearch Group) list for their useful comments, and to Dan Harkinsfor providing test vectors.7. References7.1. Normative References[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104,February 1997.[KEYWORDS] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[SHS] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-3, October 2008.7.2. Informative References[1363a] Institute of Electrical and Electronics Engineers, "IEEE Standard Specifications for Public-Key Cryptography -Amendment 1: Additional Techniques", IEEE Std1363a-2004, 2004.[800-108] National Institute of Standards and Technology,"Recommendation for Key Derivation Using PseudorandomFunctions", NIST Special Publication 800-108,November 2008.[800-56A] National Institute of Standards and Technology,"Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NISTSpecial Publication 800-56A, March 2007.[EAP-AKA] Arkko, J., Lehtovirta, V., and P. Eronen, "ImprovedExtensible Authentication Protocol Method for 3rdGeneration Authentication and Key Agreement (EAP-AKA’)", RFC 5448, May 2009.[HKDF-paper] Krawczyk, H., "Cryptographic Extraction and KeyDerivation: The HKDF Scheme", Proceedings of CRYPTO 2010 (to appear), 2010, </2010/264>.[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)Protocol", RFC 4306, December 2005.Krawczyk & Eronen Informational [Page 8][PANA] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.[PKCS5] Kaliski, B., "PKCS #5: Password-Based CryptographySpecification Version 2.0", RFC 2898, September 2000. Krawczyk & Eronen Informational [Page 9]Appendix A. Test VectorsThis appendix provides test vectors for SHA-256 and SHA-1 hashfunctions [SHS].A.1. Test Case 1Basic test case with SHA-256Hash = SHA-256IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)salt = 0x000102030405060708090a0b0c (13 octets)info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets)L = 42PRK = 0x077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5 (32 octets)OKM = 0x3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865 (42 octets)Krawczyk & Eronen Informational [Page 10]Test with SHA-256 and longer inputs/outputsHash = SHA-256IKM = 0x000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f404142434445464748494a4b4c4d4e4f (80 octets)salt = 0x606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9fa0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets)info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebfc0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedfe0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets)L = 82PRK = 0x06a6b88c5853361a06104c9ceb35b45cef760014904671014a193f40c15fc244 (32 octets)OKM = 0xb11e398dc80327a1c8e7f78c596a49344f012eda2d4efad8a050cc4c19afa97c59045a99cac7827271cb41c65e590e09da3275600c2f09b8367793a9aca3db71cc30c58179ec3e87c14c01d5c1f3434f1d87 (82 octets)A.3. Test Case 3Test with SHA-256 and zero-length salt/infoHash = SHA-256IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)salt = (0 octets)info = (0 octets)L = 42PRK = 0x19ef24a32c717b167f33a91d6f648bdf96596776afdb6377ac434c1c293ccb04 (32 octets)OKM = 0x8da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8 (42 octets)Krawczyk & Eronen Informational [Page 11]Basic test case with SHA-1Hash = SHA-1IKM = 0x0b0b0b0b0b0b0b0b0b0b0b (11 octets)salt = 0x000102030405060708090a0b0c (13 octets)info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets)L = 42PRK = 0x9b6c18c432a7bf8f0e71c8eb88f4b30baa2ba243 (20 octets)OKM = 0x085a01ea1b10f36933068b56efa5ad81a4f14b822f5b091568a9cdd4f155fda2c22e422478d305f3f896 (42 octets)A.5. Test Case 5Test with SHA-1 and longer inputs/outputsHash = SHA-1IKM = 0x000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f404142434445464748494a4b4c4d4e4f (80 octets)salt = 0x606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9fa0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets)info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebfc0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedfe0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets)L = 82PRK = 0x8adae09a2a307059478d309b26c4115a224cfaf6 (20 octets)OKM = 0x0bd770a74d1160f7c9f12cd5912a06ebff6adcae899d92191fe4305673ba2ffe8fa3f1a4e5ad79f3f334b3b202b2173c486ea37ce3d397ed034c7f9dfeb15c5e927336d0441f4c4300e2cff0d0900b52d3b4 (82 octets)Krawczyk & Eronen Informational [Page 12]Test with SHA-1 and zero-length salt/infoHash = SHA-1IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)salt = (0 octets)info = (0 octets)L = 42PRK = 0xda8c8a73c7fa77288ec6f5e7c297786aa0d32d01 (20 octets)OKM = 0x0ac1af7002b3d761d1e55298da9d0506b9ae52057220a306e07b6b87e8df21d0ea00033de03984d34918 (42 octets)A.7. Test Case 7Test with SHA-1, salt not provided (defaults to HashLen zero octets), zero-length infoHash = SHA-1IKM = 0x0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c (22 octets)salt = not provided (defaults to HashLen zero octets)info = (0 octets)L = 42PRK = 0x2adccada18779e7c2077ad2eb19d3f3e731385dd (20 octets)OKM = 0x2c91117204d745f3500d636a62f64f0ab3bae548aa53d423b0d1f27ebba6f5e5673a081d70cce7acfc48 (42 octets)Krawczyk & Eronen Informational [Page 13]Authors’ AddressesHugo KrawczykIBM Research19 Skyline DriveHawthorne, NY 10532USAEMail: hugokraw@Pasi EronenNokia Research CenterP.O. Box 407FI-00045 Nokia GroupFinlandEMail: pasi.eronen@Krawczyk & Eronen Informational [Page 14]。

Network Working Group J. Galbraith Request for Comments: 4716 VanDyke Software Category: Informational R. Thayer Canola & Jones November 2006 The Secure Shell (SSH) Public Key File FormatStatus of This MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The IETF Trust (2006).AbstractThis document formally documents an existing public key file formatin use for exchanging public keys between different Secure Shell(SSH) implementations.In addition, this document defines a standard textual representation for SSH public key fingerprints.Table of Contents1. Introduction (2)2. Conventions Used in This Document (2)3. Key File Format (2)3.1. Line Termination Characters (2)3.2. Begin and End Markers (3)3.3. Key File Header (3)3.3.1. Subject Header (3)3.3.2. Comment Header (4)3.3.3. Private Use Headers (4)3.4. Public Key File Body (4)3.5. Differences with RFC 1421 PEM Formats (4)3.6. Examples (5)4. Public Key Fingerprints (6)5. IANA Considerations (6)6. Security Considerations (7)7. References (8)7.1. Normative References (8)7.2. Informative References (8)Galbraith & Thayer Informational [Page 1]1. IntroductionThe SSH protocol supports the use of public/private key pairs inorder to perform authentication based on public key cryptography.However, in order to use public key authentication in the SSHprotocol, public keys must first be exchanged between client andserver.This document formally describes an existing public key file formatthat can be used with any of the common existing file transfermechanisms in order to exchange public keys.The SSH protocol also uses public/private key pairs to authenticatethe server. In this scenario, it is important to verify that thepublic key provided by the server is indeed the server’s public key. This document describes a mechanism for creating a short text string that uniquely represents a particular public key, calledfingerprinting.2. Conventions Used in This DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].3. Key File FormatIn order to implement public key authentication, SSH implementations must share public key files between the client and the server inorder to interoperate.A key file is a text file, containing a sequence of lines. Each line in the file MUST NOT be longer than 72 8-bit bytes excluding linetermination characters.3.1. Line Termination CharactersImplementations SHOULD generate public key files using their system’s local text file representation.In the event that public key files are not transferred as text files, implementations SHOULD be prepared to read files using any of thecommon line termination sequence, <CR>, <LF>, or <CR><LF>.Galbraith & Thayer Informational [Page 2]3.2. Begin and End MarkersThe first line of a conforming key file MUST be a begin marker, which is the literal text:---- BEGIN SSH2 PUBLIC KEY ----The last line of a conforming key file MUST be an end marker, whichis the literal text:---- END SSH2 PUBLIC KEY ----3.3. Key File HeaderThe key file header section consists of multiple RFC822-style header fields. Each field is a line of the following format:Header-tag ’:’ ’ ’ Header-valueThe Header-tag MUST NOT be more than 64 8-bit bytes and is case-insensitive. The Header-value MUST NOT be more than 1024 8-bitbytes. Each line in the header MUST NOT be more than 72 8-bit bytes.A line is continued if the last character in the line is a ’\’. Ifthe last character of a line is a ’\’, then the logical contents ofthe line are formed by removing the ’\’ and the line terminationcharacters, and appending the contents of the next line.The Header-tag MUST be encoded in US-ASCII. The Header-value MUST be encoded in UTF-8 [RFC3629].A line that is not a continuation line that has no ’:’ in it is thefirst line of the base64-encoded body. (See Section 3.4.)The space of header-tags is managed as described in Section 5.Compliant implementations MUST ignore headers with unrecognizedheader-tags. Implementations SHOULD preserve such unrecognizedheaders when manipulating the key file.3.3.1. Subject HeaderThis field is used to store the login-name that the key was generated under. For example:Subject: userGalbraith & Thayer Informational [Page 3]3.3.2. Comment HeaderThe comment header contains a user-specified comment. The commentSHOULD be displayed when using the key.It is suggested that this field default to user@hostname for the user and machine used to generate the key. For example:Comment: user@Currently, common practice is to quote the Header-value of theComment by prefixing and suffixing it with ’"’ characters, and someexisting implementations fail if these quotation marks are omitted.Compliant implementations MUST function correctly if the quotationmarks are omitted.Implementations MAY include the quotation marks. If the first andlast characters of the Header-value are matching quotation marks,implementations SHOULD remove them before using the value.3.3.3. Private Use HeadersHeaders with header-tags beginning with "x-" are reserved for private use.3.4. Public Key File BodyThe body of a public key file is the base64 encoded ([RFC2045])public key data as specified by [RFC4253], Section 6.6:string certificate or public key format identifierbyte[n] key/certificate dataAs with all other lines, each line in the body MUST NOT be longerthan 72 8-bit bytes excluding line termination characters.3.5. Differences with RFC 1421 PEM FormatsImplementers should take care to notice that while the format issuperficially similar to those specified by PEM [RFC1421] and OpenPGP [RFC2440], it is not identical; most notably:o The other specifications use different BEGIN/END delimiters (five dashes, no space rather than four dashes and a space).o There is no blank line before the start of the base64-encodedcontents.Galbraith & Thayer Informational [Page 4]o There is no Cyclic Redundancy Check (CRC) at the end of thebase64-encoded block.o Header continuation uses a backslash at the end of the continuedline rather than whitespace at the start of the next line.3.6. ExamplesThe following are some examples of public key files that arecompliant (note that the examples all wrap before 72 bytes to meetIETF document requirements; however, they are still compliant.)---- BEGIN SSH2 PUBLIC KEY ----Comment: "1024-bit RSA, converted from OpenSSH by me@"x-command: /home/me/bin/lock-in-guest.shAAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE=---- END SSH2 PUBLIC KEY -------- BEGIN SSH2 PUBLIC KEY ----Comment: This is my public key for use on \servers which I don’t like.AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV---- END SSH2 PUBLIC KEY -------- BEGIN SSH2 PUBLIC KEY ----Comment: DSA Public Key for use with MyIspAAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV---- END SSH2 PUBLIC KEY ----Galbraith & Thayer Informational [Page 5]---- BEGIN SSH2 PUBLIC KEY ----Subject: meComment: 1024-bit rsa, created by me@ Mon Jan 15 \08:31:24 2001AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0=---- END SSH2 PUBLIC KEY ----4. Public Key FingerprintsThe security of the SSH protocols relies on the verification ofpublic host keys. Since public keys tend to be very large, it isdifficult for a human to verify an entire host key. Even with aPublic Key Infrastructure (PKI) in place, it is useful to have astandard for exchanging short fingerprints of public keys.This section formally describes the method of generating public keyfingerprints that is in common use in the SSH community.The fingerprint of a public key consists of the output of the MD5message-digest algorithm [RFC1321]. The input to the algorithm isthe public key data as specified by [RFC4253]. (This is the samedata that is base64 encoded to form the body of the public key file.)The output of the algorithm is presented to the user as a sequence of 16 octets printed as hexadecimal with lowercase letters and separated by colons.For example: "c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87"5. IANA ConsiderationsSection 3.3 defines a new namespace of "Header-tags". These areUS-ASCII strings of maximum length 64 characters and arecase-insensitive.IANA has created and maintains a registry of these header-tags. The registry maps each header-tag to a reference defining the header.The initial contents of the registry are as follows:subject defined in Section 3.3.1comment defined in Section 3.3.2Header-tags beginning with "x-" are reserved for private use, asdefined in [RFC2434].Galbraith & Thayer Informational [Page 6]All other allocations are to be made by IETF consensus, as defined in [RFC2434].6. Security ConsiderationsThe file format described by this document provides no mechanism toverify the integrity or otherwise detect tampering with the datastored in such files. Given the potential of adversarial tamperingwith this data, system-specific measures (e.g., Access Control Lists, UNIX permissions, other Discretionary and/or Mandatory AccessControls) SHOULD be used to protect these files. Also, if thecontents of these files are transferred it SHOULD be done over atrusted channel.The header data allowed by this file format could contain anunlimited range of information. While in many environments theinformation conveyed by this header data may be considered innocuous public information, it may constitute a channel through whichinformation about a user, a key, or its use may be disclosedintentionally or otherwise (e.g., "Comment: Mary E. Jones, 123 MainSt, Home Phone:..."). The presence and use of this header dataSHOULD be reviewed by sites that deploy this file format.The public key fingerprint method presented here relies on the MD5one-way hash function, which is known to have certain weaknessesregarding its collision resistance; however, the particular use made of MD5 here depends solely on its 2nd-preimage resistance, not on its collision resistance.MD5 is used here for historical reasons.Galbraith & Thayer Informational [Page 7]7. References7.1. Normative References[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet MailExtensions (MIME) Part One: Format of Internet MessageBodies", RFC 2045, November 1996.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO10646", STD 63, RFC 3629, November 2003.[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)Transport Layer Protocol", RFC 4253, January 2006.[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing anIANA Considerations Section in RFCs", BCP 26, RFC 2434,October 1998.7.2. Informative References[RFC1421] Linn, J., "Privacy Enhancement for Internet ElectronicMail: Part I: Message Encryption and AuthenticationProcedures", RFC 1421, February 1993.[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,"OpenPGP Message Format", RFC 2440, November 1998.Galbraith & Thayer Informational [Page 8]Authors’ AddressesJoseph GalbraithVanDyke Software4848 Tramway Ridge BlvdSuite 101Albuquerque, NM 87111USPhone: +1 505 332 5700EMail: galb@Rodney ThayerCanola & Jones650 Castro Street Suite 120-205Mountain View CA 94041USPhone: +1 650 704 8389EMail: rodney@Galbraith & Thayer Informational [Page 9]Full Copyright StatementCopyright (C) The IETF Trust (2006).This document is subject to the rights, licenses and restrictionscontained in BCP 78, and except as set forth therein, the authorsretain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THATTHE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULARPURPOSE.Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can befound in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repository at /ipr.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. Please address the information to the IETF atietf-ipr@.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Galbraith & Thayer Informational [Page 10]。

rfc 3174标准RFC 3174标准介绍RFC（Request for Comments）3174是一项用于计算机网络中数据完整性校验的标准。

该标准定义了一种安全散列算法，即SHA-1（Secure Hash Algorithm 1）算法，用于验证数据在传输过程中是否被篡改。

SHA-1算法是美国国家安全局（NSA）设计的一种加密散列函数。

它将任意大小的数据块映射为一个固定长度的哈希值，通常为160位。

哈希值是一个数字指纹，用于唯一标识原始数据。

SHA-1算法使用了一系列复杂的位操作和逻辑函数来执行数据转换，以确保数据和哈希值之间的关联性。

RFC 3174标准的主要目的是提供一种机制来验证数据的完整性，以解决数据篡改的问题。

在现代互联网中，数据传输时存在被黑客篡改的风险。

如果数据在传输过程中被篡改，接收方将无法确定数据是否真实，从而产生安全隐患。

通过使用SHA-1算法，发送方可以将数据进行哈希运算并生成哈希值，然后将哈希值附加到数据中一起传输。

接收方可以使用相同的算法对接收到的数据进行计算，并将计算出的哈希值与附加的哈希值进行比较。

如果两个哈希值匹配，即可确认数据的完整性，并且可以安全地使用接收到的数据。

SHA-1算法具有以下特点，使其成为数据完整性校验的理想选择：1. 不可逆性：SHA-1算法将数据转换为固定长度的哈希值，不同的数据将生成不同的哈希值。

但是，无法通过哈希值推导出原始数据，使得黑客无法从哈希值中了解任何有关原始数据的信息。

2. 高度敏感性：SHA-1算法对数据的任何改动都会导致不同的哈希值。

即使是对原始数据进行微小的修改，也会显著改变哈希值，从而保证了数据完整性的检测。

3. 速度较快：SHA-1算法的计算速度较快，适用于大规模数据的处理。

这样可以确保数据的完整性校验不会成为传输过程中的瓶颈。

尽管SHA-1算法在数据完整性校验方面表现出色，但是随着计算能力的增强和密码破解技术的不断发展，SHA-1算法已经不再被认为是安全的加密散列函数。