下载文档原格式
1.引言本文档定义了扩展认证协议，一个支持多路认证方法的认证框架。
EAP通常直接运行在数据链路层，例如PPP协议或者是IEEE802,不需要IP地址。
EAP自身支持消除重复和转发，但是它依赖于底层正确的排序。
EAP本身不支持分片，然而特别的EAP方法可能支持这个。
EAP架构的优势之一就是它的灵活性。
EAP是用来选择一个专门的认证方法，通常是在认证方在得到更多的信息以后决定使用什么专门的认证方法。
与其让认证方不断更新来支持每个新的认证方法相比，EAP更倾向于使用后台认证服务器，它可以实现一些或所有认证方法，此时认证方工作于传递模式。
1.1要求说明书1.2术语本文档经常使用下列词语：认证方：启动EAP认证的链路终端。
被认证方：回应认证方的链路终端。
（也就是客户端）客户端：在IEEE802.1X中，链路终端回应被认证方。
在本文档中，这个链路终端被称为被认证方。
后台认证服务器：后台认证服务器是一个提供认证服务给认证方的实体。
当被使用时，这个服务器通常为认证方使用EAP方法。
（也就是AAA服务器）AAA：认证，授权和计费。
支持EAP的AAA协议支持包括RADIUS和Diameter。
在这个文档中，AAA服务器和后台认证服务器这两个术语是相同的意思。
EAP服务器：终止和被认证方进行EAP认证方法的实体。
在没有后台认证服务器时，EAP服务器是认证方的一部分。
在认证方工作在传递模式的情况下，EAP服务器相当于后台认证服务器。
简单丢弃：这意味着执行操作没有做进一步处理的能力，只是将数据包简单的丢弃。
该执行应该提供记录错误的能力，如丢弃包的内容；并在统计处记录下该事件。
成功认证：在本文档中，成功认证是一个EAP消息的交换，同样也是认证方决定允许被认证方访问和被认证方决定访问的结果。
认证方的决定通常包括认证和授权两个方面；被认证方可能已经成功的向认证方得以认证，但是访问可能由于政策原因被认证方拒绝。
消息完整性检查：主要的哈希函数用于认证和数据完整性保护。
Network Working Group R. Housley Request for Comments: 5652 Vigil Security Obsoletes: 3852 September 2009 Category: Standards TrackCryptographic Message Syntax (CMS)AbstractThis document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encryptarbitrary message content.Status of This MemoThis document specifies an Internet standards track protocol for the Internet 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 and License NoticeCopyright (c) 2009 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 BSD License.This document may contain material from IETF Documents or IETFContributions published or made publicly available before November10, 2008. The person(s) controlling the copyright in some of thismaterial may not have granted the IETF Trust the right to allowmodifications of such material outside the IETF Standards Process.Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modifiedoutside the IETF Standards Process, and derivative works of it maynot be created outside the IETF Standards Process, except to formatit for publication as an RFC or to translate it into languages other than English.Housley Standards Track [Page 1]Table of Contents1. Introduction (3)1.1. Evolution of the CMS (4)1.1.1. Changes Since PKCS #7 Version 1.5 (4)1.1.2. Changes Since RFC 2630 (4)1.1.3. Changes Since RFC 3369 (5)1.1.4. Changes Since RFC 3852 (5)1.2. Terminology (5)1.3. Version Numbers (6)2. General Overview (6)3. General Syntax (7)4. Data Content Type (7)5. Signed-data Content Type (8)5.1. SignedData Type (9)5.2. EncapsulatedContentInfo Type (11)5.2.1. Compatibility with PKCS #7 (12)5.3. SignerInfo Type (13)5.4. Message Digest Calculation Process (16)5.5. Signature Generation Process (16)5.6. Signature Verification Process (17)6. Enveloped-Data Content Type (17)6.1. EnvelopedData Type (18)6.2. RecipientInfo Type (21)6.2.1. KeyTransRecipientInfo Type (22)6.2.2. KeyAgreeRecipientInfo Type (23)6.2.3. KEKRecipientInfo Type (25)6.2.4. PasswordRecipientInfo Type (26)6.2.5. OtherRecipientInfo Type (27)6.3. Content-encryption Process (27)6.4. Key-Encryption Process (28)7. Digested-Data Content Type (28)8. Encrypted-Data Content Type (29)9. Authenticated-Data Content Type (30)9.1. AuthenticatedData Type (31)9.2. MAC Generation (33)9.3. MAC Verification (34)10. Useful Types (34)10.1. Algorithm Identifier Types (35)10.1.1. DigestAlgorithmIdentifier (35)10.1.2. SignatureAlgorithmIdentifier (35)10.1.3. KeyEncryptionAlgorithmIdentifier (35)10.1.4. ContentEncryptionAlgorithmIdentifier (36)10.1.5. MessageAuthenticationCodeAlgorithm (36)10.1.6. KeyDerivationAlgorithmIdentifier (36)10.2. Other Useful Types (36)10.2.1. RevocationInfoChoices (36)10.2.2. CertificateChoices (37)Housley Standards Track [Page 2]10.2.3. CertificateSet (38)10.2.4. IssuerAndSerialNumber (38)10.2.5. CMSVersion (39)10.2.6. UserKeyingMaterial (39)10.2.7. OtherKeyAttribute (39)11. Useful Attributes (39)11.1. Content Type (40)11.2. Message Digest (40)11.3. Signing Time (41)11.4. Countersignature (42)12. ASN.1 Modules (43)12.1. CMS ASN.1 Module (44)12.2. Version 1 Attribute Certificate ASN.1 Module (51)13. References (52)13.1. Normative References (52)13.2. Informative References (53)14. Security Considerations (54)15. Acknowledgments (56)1. IntroductionThis document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encryptarbitrary message content.The CMS describes an encapsulation syntax for data protection. Itsupports digital signatures and encryption. The syntax allowsmultiple encapsulations; one encapsulation envelope can be nestedinside another. Likewise, one party can digitally sign somepreviously encapsulated data. It also allows arbitrary attributes,such as signing time, to be signed along with the message content,and it provides for other attributes such as countersignatures to be associated with a signature.The CMS can support a variety of architectures for certificate-based key management, such as the one defined by the PKIX (Public KeyInfrastructure using X.509) working group [PROFILE].The CMS values are generated using ASN.1 [X.208-88], using BER-encoding (Basic Encoding Rules) [X.209-88]. Values are typicallyrepresented as octet strings. While many systems are capable oftransmitting arbitrary octet strings reliably, it is well known that many electronic mail systems are not. This document does not address mechanisms for encoding octet strings for reliable transmission insuch environments.Housley Standards Track [Page 3]1.1. Evolution of the CMSThe CMS is derived from PKCS #7 version 1.5, which is documented inRFC 2315 [PKCS#7]. PKCS #7 version 1.5 was developed outside of the IETF; it was originally published as an RSA Laboratories TechnicalNote in November 1993. Since that time, the IETF has takenresponsibility for the development and maintenance of the CMS.Today, several important IETF Standards-Track protocols make use ofthe CMS.This section describes that changes that the IETF has made to the CMS in each of the published versions.1.1.1. Changes Since PKCS #7 Version 1.5RFC 2630 [CMS1] was the first version of the CMS on the IETFStandards Track. Wherever possible, backward compatibility with PKCS #7 version 1.5 is preserved; however, changes were made toaccommodate version 1 attribute certificate transfer and to supportalgorithm-independent key management. PKCS #7 version 1.5 includedsupport only for key transport. RFC 2630 adds support for keyagreement and previously distributed symmetric key-encryption keytechniques.1.1.2. Changes Since RFC 2630RFC 3369 [CMS2] obsoletes RFC 2630 [CMS1] and RFC 3211 [PWRI].Password-based key management is included in the CMS specification,and an extension mechanism to support new key management schemeswithout further changes to the CMS is specified. Backwardcompatibility with RFC 2630 and RFC 3211 is preserved; however,version 2 attribute certificate transfer is added, and the use ofversion 1 attribute certificates is deprecated.Secure/Multipurpose Internet Mail Extensions (S/MIME) v2 signatures[MSG2], which are based on PKCS #7 version 1.5, are compatible withS/MIME v3 signatures [MSG3]and S/MIME v3.1 signatures [MSG3.1].However, there are some subtle compatibility issues with signaturesbased on PKCS #7 version 1.5. These issues are discussed in Section 5.2.1. These issues remain with the current version of the CMS.Specific cryptographic algorithms are not discussed in this document, but they were discussed in RFC 2630. The discussion of specificcryptographic algorithms has been moved to a separate document[CMSALG]. Separation of the protocol and algorithm specificationsallows the IETF to update each document independently. Thisspecification does not require the implementation of any particular Housley Standards Track [Page 4]algorithms. Rather, protocols that rely on the CMS are expected tochoose appropriate algorithms for their environment. The algorithms may be selected from [CMSALG] or elsewhere.1.1.3. Changes Since RFC 3369RFC 3852 [CMS3] obsoletes RFC 3369 [CMS2]. As discussed in theprevious section, RFC 3369 introduced an extension mechanism tosupport new key management schemes without further changes to theCMS. RFC 3852 introduces a similar extension mechanism to supportadditional certificate formats and revocation status informationformats without further changes to the CMS. These extensions areprimarily documented in Sections 10.2.1 and 10.2.2. Backwardcompatibility with earlier versions of the CMS is preserved.The use of version numbers is described in Section 1.3.Since the publication of RFC 3369, a few errata have been noted.These errata are posted on the RFC Editor web site. These errorshave been corrected in this document.The text in Section 11.4 that describes the counter signatureunsigned attribute is clarified. Hopefully, the revised text isclearer about the portion of the SignerInfo signature that is covered by a countersignature.1.1.4. Changes Since RFC 3852This document obsoletes RFC 3852 [CMS3]. The primary reason for the publication of this document is to advance the CMS along thestandards maturity ladder.This document includes the clarifications that were originallypublished in RFC 4853 [CMSMSIG] regarding the proper handling of the SignedData protected content type when more than one digitalsignature is present.Since the publication of RFC 3852, a few errata have been noted.These errata are posted on the RFC Editor web site. These errorshave been corrected in this document.1.2. TerminologyIn this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted asdescribed in [STDWORDS].Housley Standards Track [Page 5]1.3. Version NumbersEach of the major data structures includes a version number as thefirst item in the data structure. The version numbers are intendedto avoid ASN.1 decode errors. Some implementations do not check the version number prior to attempting a decode, and if a decode erroroccurs, then the version number is checked as part of the errorhandling routine. This is a reasonable approach; it places errorprocessing outside of the fast path. This approach is also forgiving when an incorrect version number is used by the sender.Most of the initial version numbers were assigned in PKCS #7 version 1.5. Others were assigned when the structure was initially created. Whenever a structure is updated, a higher version number is assigned. However, to ensure maximum interoperability, the higher versionnumber is only used when the new syntax feature is employed. Thatis, the lowest version number that supports the generated syntax isused.2. General OverviewThe CMS is general enough to support many different content types.This document defines one protection content, ContentInfo.ContentInfo encapsulates a single identified content type, and theidentified type may provide further encapsulation. This documentdefines six content types: data, signed-data, enveloped-data,digested-data, encrypted-data, and authenticated-data. Additionalcontent types can be defined outside this document.An implementation that conforms to this specification MUST implement the protection content, ContentInfo, and MUST implement the data,signed-data, and enveloped-data content types. The other contenttypes MAY be implemented.As a general design philosophy, each content type permits single pass processing using indefinite-length Basic Encoding Rules (BER)encoding. Single-pass operation is especially helpful if content is large, stored on tapes, or is "piped" from another process. Single- pass operation has one significant drawback: it is difficult toperform encode operations using the Distinguished Encoding Rules(DER) [X.509-88] encoding in a single pass since the lengths of thevarious components may not be known in advance. However, signedattributes within the signed-data content type and authenticatedattributes within the authenticated-data content type need to betransmitted in DER form to ensure that recipients can verify acontent that contains one or more unrecognized attributes. Signedattributes and authenticated attributes are the only data types used in the CMS that require DER encoding.Housley Standards Track [Page 6]3. General SyntaxThe following object identifier identifies the content informationtype:id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }The CMS associates a content type identifier with a content. Thesyntax MUST have ASN.1 type ContentInfo:ContentInfo ::= SEQUENCE {contentType ContentType,content [0] EXPLICIT ANY DEFINED BY contentType }ContentType ::= OBJECT IDENTIFIERThe fields of ContentInfo have the following meanings:contentType indicates the type of the associated content. It isan object identifier; it is a unique string of integers assignedby an authority that defines the content type.content is the associated content. The type of content can bedetermined uniquely by contentType. Content types for data,signed-data, enveloped-data, digested-data, encrypted-data, andauthenticated-data are defined in this document. If additionalcontent types are defined in other documents, the ASN.1 typedefined SHOULD NOT be a CHOICE type.4. Data Content TypeThe following object identifier identifies the data content type:id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }The data content type is intended to refer to arbitrary octetstrings, such as ASCII text files; the interpretation is left to the application. Such strings need not have any internal structure(although they could have their own ASN.1 definition or otherstructure).S/MIME uses id-data to identify MIME-encoded content. The use ofthis content identifier is specified in RFC 2311 for S/MIME v2[MSG2], RFC 2633 for S/MIME v3 [MSG3], and RFC 3851 for S/MIME v3.1[MSG3.1].Housley Standards Track [Page 7]The data content type is generally encapsulated in the signed-data,enveloped-data, digested-data, encrypted-data, or authenticated-data content type.5. Signed-data Content TypeThe signed-data content type consists of a content of any type andzero or more signature values. Any number of signers in parallel can sign any type of content.The typical application of the signed-data content type representsone signer’s digital signature on content of the data content type.Another typical application disseminates certificates and certificate revocation lists (CRLs).The process by which signed-data is constructed involves thefollowing steps:1. For each signer, a message digest, or hash value, is computed on the content with a signer-specific message-digest algorithm. If the signer is signing any information other than the content, the message digest of the content and the other information aredigested with the signer’s message digest algorithm (see Section 5.4), and the result becomes the "message digest."2. For each signer, the message digest is digitally signed using the signer’s private key.3. For each signer, the signature value and other signer-specificinformation are collected into a SignerInfo value, as defined in Section 5.3. Certificates and CRLs for each signer, and thosenot corresponding to any signer, are collected in this step.4. The message digest algorithms for all the signers and theSignerInfo values for all the signers are collected together with the content into a SignedData value, as defined in Section 5.1.A recipient independently computes the message digest. This message digest and the signer’s public key are used to verify the signaturevalue. The signer’s public key is referenced in one of two ways. It can be referenced by an issuer distinguished name along with anissuer-specific serial number to uniquely identify the certificatethat contains the public key. Alternatively, it can be referenced by a subject key identifier, which accommodates both certified anduncertified public keys. While not required, the signer’scertificate can be included in the SignedData certificates field. Housley Standards Track [Page 8]When more than one signature is present, the successful validation of one signature associated with a given signer is usually treated as a successful signature by that signer. However, there are someapplication environments where other rules are needed. Anapplication that employs a rule other than one valid signature foreach signer must specify those rules. Also, where simple matching of the signer identifier is not sufficient to determine whether thesignatures were generated by the same signer, the applicationspecification must describe how to determine which signatures weregenerated by the same signer. Support of different communities ofrecipients is the primary reason that signers choose to include more than one signature. For example, the signed-data content type might include signatures generated with the RSA signature algorithm andwith the Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithm. This allows recipients to verify the signature associated with one algorithm or the other.This section is divided into six parts. The first part describes the top-level type SignedData, the second part describesEncapsulatedContentInfo, the third part describes the per-signerinformation type SignerInfo, and the fourth, fifth, and sixth partsdescribe the message digest calculation, signature generation, andsignature verification processes, respectively.5.1. SignedData TypeThe following object identifier identifies the signed-data contenttype:id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }The signed-data content type shall have ASN.1 type SignedData:SignedData ::= SEQUENCE {version CMSVersion,digestAlgorithms DigestAlgorithmIdentifiers,encapContentInfo EncapsulatedContentInfo,certificates [0] IMPLICIT CertificateSet OPTIONAL,crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,signerInfos SignerInfos }DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifierSignerInfos ::= SET OF SignerInfoHousley Standards Track [Page 9]The fields of type SignedData have the following meanings:version is the syntax version number. The appropriate valuedepends on certificates, eContentType, and SignerInfo. Theversion MUST be assigned as follows:IF ((certificates is present) AND(any certificates with a type of other are present)) OR((crls is present) AND(any crls with a type of other are present))THEN version MUST be 5ELSEIF (certificates is present) AND(any version 2 attribute certificates are present)THEN version MUST be 4ELSEIF ((certificates is present) AND(any version 1 attribute certificates are present)) OR (any SignerInfo structures are version 3) OR(encapContentInfo eContentType is other than id-data) THEN version MUST be 3ELSE version MUST be 1digestAlgorithms is a collection of message digest algorithmidentifiers. There MAY be any number of elements in thecollection, including zero. Each element identifies the messagedigest algorithm, along with any associated parameters, used byone or more signer. The collection is intended to list themessage digest algorithms employed by all of the signers, in anyorder, to facilitate one-pass signature verification.Implementations MAY fail to validate signatures that use a digest algorithm that is not included in this set. The message digesting process is described in Section 5.4.encapContentInfo is the signed content, consisting of a contenttype identifier and the content itself. Details of theEncapsulatedContentInfo type are discussed in Section 5.2.certificates is a collection of certificates. It is intended that the set of certificates be sufficient to contain certificationpaths from a recognized "root" or "top-level certificationauthority" to all of the signers in the signerInfos field. There may be more certificates than necessary, and there may becertificates sufficient to contain certification paths from two or more independent top-level certification authorities. There mayalso be fewer certificates than necessary, if it is expected that recipients have an alternate means of obtaining necessaryHousley Standards Track [Page 10]certificates (e.g., from a previous set of certificates). Thesigner’s certificate MAY be included. The use of version 1attribute certificates is strongly discouraged.crls is a collection of revocation status information. It isintended that the collection contain information sufficient todetermine whether the certificates in the certificates field arevalid, but such correspondence is not necessary. Certificaterevocation lists (CRLs) are the primary source of revocationstatus information. There MAY be more CRLs than necessary, andthere MAY also be fewer CRLs than necessary.signerInfos is a collection of per-signer information. There MAY be any number of elements in the collection, including zero. When the collection represents more than one signature, the successful validation of one of signature from a given signer ought to betreated as a successful signature by that signer. However, there are some application environments where other rules are needed.The details of the SignerInfo type are discussed in Section 5.3.Since each signer can employ a different digital signaturetechnique, and future specifications could update the syntax, all implementations MUST gracefully handle unimplemented versions ofSignerInfo. Further, since all implementations will not supportevery possible signature algorithm, all implementations MUSTgracefully handle unimplemented signature algorithms when they are encountered.5.2. EncapsulatedContentInfo TypeThe content is represented in the type EncapsulatedContentInfo:EncapsulatedContentInfo ::= SEQUENCE {eContentType ContentType,eContent [0] EXPLICIT OCTET STRING OPTIONAL }ContentType ::= OBJECT IDENTIFIERThe fields of type EncapsulatedContentInfo have the followingmeanings:eContentType is an object identifier. The object identifieruniquely specifies the content type.eContent is the content itself, carried as an octet string. TheeContent need not be DER encoded.Housley Standards Track [Page 11]The optional omission of the eContent within theEncapsulatedContentInfo field makes it possible to construct"external signatures". In the case of external signatures, thecontent being signed is absent from the EncapsulatedContentInfo value included in the signed-data content type. If the eContent valuewithin EncapsulatedContentInfo is absent, then the signatureValue is calculated and the eContentType is assigned as though the eContentvalue was present.In the degenerate case where there are no signers, theEncapsulatedContentInfo value being "signed" is irrelevant. In this case, the content type within the EncapsulatedContentInfo value being "signed" MUST be id-data (as defined in Section 4), and the contentfield of the EncapsulatedContentInfo value MUST be omitted.5.2.1. Compatibility with PKCS #7This section contains a word of warning to implementers that wish to support both the CMS and PKCS #7 [PKCS#7] SignedData content types.Both the CMS and PKCS #7 identify the type of the encapsulatedcontent with an object identifier, but the ASN.1 type of the content itself is variable in PKCS #7 SignedData content type.PKCS #7 defines content as:content [0] EXPLICIT ANY DEFINED BY contentType OPTIONALThe CMS defines eContent as:eContent [0] EXPLICIT OCTET STRING OPTIONALThe CMS definition is much easier to use in most applications, and it is compatible with both S/MIME v2 and S/MIME v3. S/MIME signedmessages using the CMS and PKCS #7 are compatible because identicalsigned message formats are specified in RFC 2311 for S/MIME v2[MSG2], RFC 2633 for S/MIME v3 [MSG3], and RFC 3851 for S/MIME v3.1[MSG3.1]. S/MIME v2 encapsulates the MIME content in a Data type(that is, an OCTET STRING) carried in the SignedData contentInfocontent ANY field, and S/MIME v3 carries the MIME content in theSignedData encapContentInfo eContent OCTET STRING. Therefore, inS/MIME v2, S/MIME v3, and S/MIME v3.1, the MIME content is placed in an OCTET STRING and the message digest is computed over the identical portions of the content. That is, the message digest is computedover the octets comprising the value of the OCTET STRING, neither the tag nor length octets are included.Housley Standards Track [Page 12]There are incompatibilities between the CMS and PKCS #7 SignedDatatypes when the encapsulated content is not formatted using the Datatype. For example, when an RFC 2634 signed receipt [ESS] isencapsulated in the CMS SignedData type, then the Receipt SEQUENCE is encoded in the SignedData encapContentInfo eContent OCTET STRING and the message digest is computed using the entire Receipt SEQUENCEencoding (including tag, length and value octets). However, if anRFC 2634 signed receipt is encapsulated in the PKCS #7 SignedDatatype, then the Receipt SEQUENCE is DER encoded [X.509-88] in theSignedData contentInfo content ANY field (a SEQUENCE, not an OCTETSTRING). Therefore, the message digest is computed using only thevalue octets of the Receipt SEQUENCE encoding.The following strategy can be used to achieve backward compatibility with PKCS #7 when processing SignedData content types. If theimplementation is unable to ASN.1 decode the SignedData type usingthe CMS SignedData encapContentInfo eContent OCTET STRING syntax,then the implementation MAY attempt to decode the SignedData typeusing the PKCS #7 SignedData contentInfo content ANY syntax andcompute the message digest accordingly.The following strategy can be used to achieve backward compatibility with PKCS #7 when creating a SignedData content type in which theencapsulated content is not formatted using the Data type.Implementations MAY examine the value of the eContentType, and thenadjust the expected DER encoding of eContent based on the objectidentifier value. For example, to support Microsoft Authenticode[MSAC], the following information MAY be included:eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 } eContent contains DER-encoded Authenticode signing information5.3. SignerInfo TypePer-signer information is represented in the type SignerInfo:SignerInfo ::= SEQUENCE {version CMSVersion,sid SignerIdentifier,digestAlgorithm DigestAlgorithmIdentifier,signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,signatureAlgorithm SignatureAlgorithmIdentifier,signature SignatureValue,unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }Housley Standards Track [Page 13]。
Juniper SRX防火墙简明配置手册目录一、 JUNOS 操作系统介绍 (3)1.1层次化配置结构 (3)1.2 JunOS 配置管理 (4)1.3 SRX 主要配置内容 (4)二、 SRX 防火墙配置说明 (5)2.1初始安装 (5)2.1.1登陆 (5)2.1.2设置 root 用户口令 (9)2.1.3JSRP 初始化配置 (9)2.1.4设置远程登陆管理用户 (14)2.1.5远程管理 SRX相关配置 (15)2.1.6ZONE 及相关接口的配置 (15)2.2 Policy (16)2.3 NAT (17)2.3.1Interface based NAT (18)2.3.2Pool based Source NAT (18)2.3.3Pool base destination NAT (19)2.3.4Pool base Static NAT (20)2.4 IPSEC VPN (21)2.5 Application and ALG (22)三、 SRX 防火墙常规操作与维护 (22)3.1单机设备关机 (22)3.2单机设备重启 (23)3.3单机操作系统升级 (23)3.4双机模式下主备 SRX 关机 (23)3.5双机模式下主备设备重启 (24)3.6双机模式下操作系统升级 (24)3.7双机转发平面主备切换及切换后恢复 (25)3.8双机控制平面主备切换及切换后恢复 (25)3.9双机模式下更换备SRX (25)3.10双机模式下更换主SRX (26)3.11双机模式更换电源 (27)3.12双机模式更换故障板卡 (27)3.13配置备份及还原方法 (27)3.14密码修改方法 (28)3.15磁盘文件清理方法 (28)3.16密码恢复 (28)3.17常用监控维护命令 (29)四、 SRX 防火墙介绍 (31)Juniper SRX防火墙简明配置手册SRX系列防火墙是 Juniper 公司基于 JUNOS操作系统的安全系列产品，JUNOS集成了路由、交换、安全性和一系列丰富的网络服务。
本文翻译者：weicq2000RFC 6071 IP安全(IPsec)和互联网密钥交换(IKE)文件路线图(2011年2月)RFC 6071废止了RFC 2411。
摘要过去几年，定义和使用IP安全(IPsec)和互联网密钥交换(Internet Key Exchange, IKE)的RFCs数量急剧增长。
造成这种复杂情况的主要原因是这些RFCs源于许多IETF工作组：最初的IPsec 工作组，它的各种衍生组织，以及其他使用IPsec和/或IKE来保护它们的协议流量的工作组。
本文件归纳与IPsec和IKE有关的RFCs。
包括对每个RFC的简短描述，伴随背景信息介绍IPsec成长和扩展的动机及其来龙去脉。
本文件废止了RFC2411，先前的“IP安全文件路线图”。
[RFC-2411]简单描述各种等级基本IPsec文件的相互关系。
[RFC-2411]的要点是说明文件的建议内容，这些文件规定附加加密和认证算法。
本备忘录状态本文件不是互联网标准跟踪(Internet Standards Track)规范；出版它是出于提供信息目的。
本文件是互联网工程任务组(Internet Engineering Task Force, IETF)的作品。
它代表IETF 社会的共识。
它收到了公众评价并已获得互联网工程指导组(Internet Engineering Steering Group, IESG)认可和获准出版。
由IESG批准的文件不一定都是某个层次互联网标准的候选方案；参阅RFC5741第2章。
有关本文件目前状态信息，任何错误，以及如何得到有关它的反馈可以浏览：/info/rfc6071。
版权声明Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (/license-info) in effect on the date of publication of this document. Please review these documents carefully, 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 of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modifiedoutside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it intolanguages other than English.目录第1章序言第2章IPsec/IEK背景信息2-1 IPsec/IKE文件相互关系2-2 IPsec版本2-2-1 “旧”IPsec (IPsec-v2)和“新”IPsec (IPsec-v3)的不同2-3 IKE版本2-3-1 IKEv1和IKEv2的不同2-4 IPsec和IKE的IANA注册第3章IPsec文件3-1 基本文件3-1-1 “旧”IPsec (IPsec-v2)3-1-2 “新”IPsec (IPsec-v3)3-2 对IPsec的补充3-3 一般考虑第4章IKE文件4-1 基本文件4-1-1 IKEv14-1-2 IKEv24-2 补充和扩展4-2-1 对端认证方法4-2-2 证书内容和管理(PKI4IPsec)4-2-3 失效的对端检查4-2-4 远程访问第5章密码算法和套件5-1 算法要求5-2 加密算法5-3 完整性保护(认证)算法5-4 组合模式算法5-5 伪随机函数(PRFs)5-6 密码套件5-7 迪菲赫尔曼算法第6章多播的IPsec/IKE第7章IPsec/IKE派生物7-1 IPsec策略7-2 IPsec MIBs7-3 IP压缩( IPComp)7-4 有比没有好安全(BTNS)策略7-5 密钥的Kerberized互联网协商(KINK)7-6 IPsec安全远程访问(IPSRA)7-7 IPsec密钥信息资源记录(IPSECKEY)第8章使用IPsec/IKE的其他协议8-1 移动IP(MIPv4和MIPv6)8-2 开放最短路径优先(OSPF)8-3 主机标识协议(HIP)8-4 流控制传输协议(SCTP)8-5 茁壮首部压缩(ROHC)8-6 边界网关协议(BGP)8-7 IPsec 基准(测试)8-8 网络地址转换器(NAT)8-9 会话发起协议(SIP)8-10 显示分组灵敏度标签第9章其他采纳非IPsec功能IKE的协议9-1 可扩展认证协议(EAP)9-2 光纤通道9-3 无线安全第10章致谢第11章安全考虑第12章参考文献12-1 信息性参考文献附录A 算法要求等级归纳第1章序言互联网协议安全(Internet Protocol Security, IPsec)是一组协议，它在IP层对互联网通信提供安全保证。
核心交换机双机热备解决方案一、项目背景稳定持续的系网络系统运行变得越来越重要，而原来有单机核心三层交换数据潜 伏巨大的崩溃风险。
VRRP （虚拟路由冗余协议）技术来解决该问题，以实现主、备核心三层交换设 备之间动态、无停顿的热切换。
二、方案设计：2.1、 简要介绍VRRP 的基本概念。
通常情况下，内部网络中的所有主机都设置一条相同的缺省路由，指向出口网关 （即图1中的交换机S9300A ），实现主机与外部网络的通信。
当出口网关发生 故障时，主机与外部网络的通信就会中断。
图1局域网缺省网关Gateway: 10,0.0.1 IP Address:10,0.0.4/24 4Ethernet 配置多个出口网关是提高系统可靠性的常见方法，但需要解决如何在多个出口网 关之间进行选路的问题。
VRRP （Virtual Router Redundancy Protocol ）是 RFC3768 定义的一种容错协议， 通过物理设备和逻辑设备的分离，实现在多个出口网关之间选路，很好地解决了 上述问题。
在具有多播或广播能力的局域网（如以太网）中，VRRP 提供逻辑网关确保高利 用度的传输链路，不仅能够解决因某网关设备故障带来的业务中断，而且无需修 改路由协议的配置。
2.2、 V RRP 工作原理：S93OOAGateway: 10.0.0.1IP Address:10,0.0.2/24Gateway: 10,0.0.1 IP Address;10.0.0.3/2410.0.0.1/24vrrp只定义了一种报文—- vrrp报文，这是一种组播报文，由主三层交换机定时发出来通告他的存在。
使用这些报文可以检测虚拟三层交换机各种参数，还可以用于主三层交换机的选举。
VRRP中定义了三种状态模型，初始状态Initialize，活动状态Master 和备份状态Backup，其中只有活动状态的交换机可以为到虚拟IP地址的的转发请求提供服务。
中国地质大学江城学院组播侦听发现（MLDv1）协议详解_RFC2710学部机械与电子信息学部班级11计网本1学号2320110102姓名王青指导教师辛玲2013年11月16 日目录Table of Contents1 MLDv1简介......................................................................................................... . (3)2 消息格式 (4)2.1 代码（Code） (4)2.2 校验和（Checksum）............................................................................... (4)2.3 最大响应延迟（Maximum Response Delay）......................................... . (5)2.4 保留（Reserved） (5)2.5 组播地址（Multicast Address）.................................................................... .. (5)2.6 其他区域（Other fields）.............................................................................. . (5)3 协议描述 (5)4 节点状态转换图.................................................................... (7)5 路由器状态转换图............................................................. ................................ . (9)6 定时器及其缺省值列表.......................................................................................... .. (13)6.1 健壮性变量（Robustness Variable）............................................................. .. (13)6.2 查询间隔（Query Interval）.......................................... .. (13)6.3 查询响应间隔（Query Response Interval）.................. .............................. . (13)6.4 组播侦听者间隔（Multicast Listener Interval）.............................. .............. (14)6.5 其他查询器存在间隔（Other Querier Present Interval）................................ . (14)6.6 启动查询间隔（Startup Query Interval）........................................................ . (14)6.7 启动查询次数（Startup Query Count） (14)6.8 最后侦听者查询间隔（Last Listener Query Interval）............................ ........ (14)6.9 最后侦听者查询次数（Last Listener Query Count）......................... (14)6.10 主动报告间隔（Unsolicited Report Interval） (14)7 消息目的地址 (14)文档标题关键词Key words：IPv6、MLD、IGMPv2本文档介绍了IPv6路由器所使用的一种协议，用以发现在其直连网络上的组播侦听者（即希望接收组播数据的节点）的存在，并且能明确发现这些邻居节点所感兴趣的组播地址。
Inspur NOS安全技术白皮书文档版本V1.0发布日期2022-12-16版权所有© 2022浪潮电子信息产业股份有限公司。
保留一切权利。
未经本公司事先书面许可，任何单位和个人不得以任何形式复制、传播本手册的部分或全部内容。
商标说明Inspur浪潮、Inspur、浪潮、Inspur NOS是浪潮集团有限公司的注册商标。
本手册中提及的其他所有商标或注册商标，由各自的所有人拥有。
技术支持技术服务电话：400-860-0011地址：中国济南市浪潮路1036号浪潮电子信息产业股份有限公司邮箱：***************邮编：250101前言文档用途本文档阐述了浪潮交换机产品Inspur NOS的安全能力及技术原理。
注意由于产品版本升级或其他原因，本文档内容会不定期进行更新。
除非另有约定，本文档仅作为使用指导，本文档中的所有陈述、信息和建议不构成任何明示或暗示的担保。
读者对象本文档提供给以下相关人员使用：●产品经理●运维工程师●售前工程师●LMT及售后工程师变更记录目录1概述 (1)2缩写和术语 (2)3威胁与挑战 (3)4安全架构 (4)5安全设计 (5)5.1账号安全 (5)5.2权限控制 (5)5.3访问控制 (6)5.4安全协议 (6)5.5数据保护 (7)5.6安全加固 (7)5.7日志审计 (7)5.8转发面安全防护 (7)5.9控制面安全防护 (8)6安全准测和策略 (9)6.1版本安全维护 (9)6.2加强账号和权限管理 (10)6.3TACACS+服务授权 (10)6.4加固系统安全 (12)6.4.1关闭不使用的服务和端口 (12)6.4.2废弃不安全通道 (12)6.4.3善用安全配置 (12)6.5关注数据安全 (13)6.6保障网络隔离 (14)6.7基于安全域访问控制 (14)6.8攻击防护 (15)6.9可靠性保护 (16)7安全发布 (18)随着开放网络的快速发展，白盒交换机做为一种软硬件解耦的开放网络设备，应用越来越广泛。
组织：中国互动出版网（/）RFC文档中文翻译计划（/compters/emook/aboutemook.htm）E-mail：ouyang@译者：张海斌（netdebug internetdebug@ ）译文发布时间：2001-11-08版权：本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
Network Working Group J. Hodges Request for Comments: 2830 Oblix Inc. Category: Standards Track R. MorganUniv of WashingtonM. WahlSun Microsystems, Inc.May 2000简单目录访问协议（v3）：传输层安全扩展（RFC2830——Lightweight Directory Access Protocol (v3):Extension for Transport Layer Security）备忘录状况这份文档为Internet社区指定为Internet标准（轨迹）协议，并且为进一步改进需要讨论和建议。
这份协议的标准化状态和状况请参阅"Internet官方协议标准（Internet Official Protocol Standards ）"(STD 1)的当前版。
这份备忘录的分发不受限制。
版权声明Copyright (C) The Internet Society (2000)。
版权所有。
摘要这份文档针对LDAP [LDAPv3, TLS]定义了 "启动传输层安全操作Start Transport Layer Security (TLS) Operation" 。
这个操作规定了与LDAP 关联的TLS建立（establishment）和按照LDAP扩展请求被定义。
目录0.译者的话 (2)1. 本文的约定 (3)2. 启动TLS 请求 (3)2.1. 请求TLS建立 (3)2.2. 成功回答（"Success" Response） (4)2.3. 回答为"success"以外的值 (4)3. 启动TLS操作的序列 (5)3.1. 在LDAP关联中启动TLS请求 (5)3.2. 启动TLS (5)3.3. TLS版本协商 (6)3.4. 结果安全级的发现（Discovery of Resultant Security Level） (6)3.5. 客户程序授权身份（Client's Authorization Identity）的断言 (6)3.6. 服务程序身份检查 (6)3.7. 服务程序能力信息的刷新 (7)4. 关闭TLS连接 (7)4.1. 舒缓关闭（Graceful Closure） (7)4.2. 突然停止（Abrupt Closure） (8)5. 关于客户程序的授权身份的TLS效应（Effects） (8)5.1. TLS连接建立效应 (8)5.1.1. 缺省效应 (8)5.1.2. 授权身份的客户断言 (8)5.1.2.1. 隐式断言（Implicit Assertion） (9)5.1.2.2. 显式断言（Explicit Assertion） (9)5.1.2.3. 错误状况（Error Conditions） (9)5.2. TLS连接关闭效应 (9)6. 安全考虑 (10)7. 确认 (10)8. 参考 (10)9. 作者地址 (11)10. 知识产权声明 (12)11. 完整版权声明 (12)确认 (13)0.译者的话译者在翻译这份文档的时候，采取直译的方式，尽量保证原文的原意。
RFC2326(中文版)-实时流协议(RTSP).txt我的人生有A 面也有B面，你的人生有S面也有B 面。
失败不可怕，关键看是不是成功他妈。
现在的大学生太没素质了！过来拷毛片，居然用剪切！有空学风水去，死后占个好墓也算弥补了生前买不起好房的遗憾。
实时流协议(RTSP) ( Real Time Streaming Protocol (RTSP) )备忘录的状态：本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。
请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化程度和状态。
本备忘录的发布不受任何限制。
版权声明：版权为The Internet Society 所有。
所有权利保留。
摘要：实时流协议（RTSP）是应用层协议，控制实时数据的传送。
RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。
数据源包括现场数据与存储在剪辑中数据。
该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP(RFC1889)上传送机制提供方法。
目录：1 绪论 51.1 目的 51.2 要求 61.3 术语 61.4 协议特点 71.5 RTSP扩展 81.6 操作模式 91.7 RTSP状态 91.8 与其他协议关系 102 符号协定 103 协议参数 103.1 RTSP版本 103.2 RTSP URL 113.3 会议标识 133.4 会话标识 133.5 SMPTE 相对时间戳 133.6正常播放时间 143.7 绝对时间 153.8 选择标签 153.8.1 用IANA注册新的选择标签 154 RTSP消息 154.1 消息类型 164.2 消息标题 174.3 消息主体 174.4 消息长度 185 普通标题域 186 请求 196.1 请求队列 196.2 请求标题域 197 回应 207.1 状态行 207.1.1 状态代码和原因分析 207.1.2 回应标题域 238 实体 238.1 实体标题域 248.2 实体主体 249 连接 259.1 流水线操作 259.2 可靠性及确认 2510 方法定义 2510.1 选择 2610.2 描述 2610.3 通告 2610.4 建立 2610.5 播放 2710.6 暂停 2710.7 断开 2710.8 获取参数 2810.9 设置参数 2810.10 重定向 2810.11 录制 2910.12 嵌入二进制数据 2911状态代码定义（Status Code Definitions） 29 11.1成功2xx（Success 2xx） 3011.1.1 存储空间低 250 3011.2 重定向（Redirection 3xx） 3111.3 客户端错误（Client Error ）4xx 3111.3.1方法不允许 3211.3.2参数不能理解 3211.3.3会议未找到 3311.3.4 带宽不足 3311.3.5 会话未找到 3411.3.6 本状态下该方法无效 3411.3.7 标题域对资源无效 3411.3.8 无效范围 3511.3.9 参数只读 3511.3.10 不允许合操作 3611.3.11 只允许合操作 3611.3.12 不支持的传输 3611.3.13 目标不可达 3711.3.14 选择不支持 3712 标题域定义（Header Field Definitions） 38 12.1 接受 3812.2 接受编码 3812.3 接受语言 3912.4 允许（Allow） 3912.5 授权（Authorization） 4012.6 带宽 4012.7 块大小 4012.8 缓存控制 4112.9 会议 4112.10 连接 4112.11 基本内容 4212.12 内容编码（Content-Encoding） 4212.13 内容语言 4312.14 内容长度（Content-Length） 4312.15 内容位置 4312.16 内容类型（Content-Type） 4412.17 序列号 4412.18 日期（Date） 4412.19 过期（Expires） 4512.20 来自（From） 4512.21 主机 4512.22 如果匹配 4512.23 从何时更改（If-Modified-Since） 46 12.24 最近更改（Last-Modified） 4612.25 位置（Location） 4612.26 代理授权 4712.27 代理要求 4712.28 公用性 4712.29 范围 4912.30 提交方（Referer） 4912.31 稍后再试 4912.32 要求 4912.33 RTP信息 4912.34 比例 4912.35 速度 4912.36 服务器（Server） 4912.37 会话 4912.38 时间戳 4912.39 传输 4912.40 不支持 4912.41 用户代理（User-Agent） 4912.42 变化 4912.43 通过 4912.44 WWW-授权（WWW-Authenticate） 5013 缓存 5014 实例 5014.1 要求媒体（单播） 5014.2 容器文件的流 5114.3 单个流容器文件 5114.4 组播现场媒体表示 5114.5 在存在的会话中播放媒体 5114.6 录制 5215 语法 5215.1 基本语法 5216 安全考虑（Security Considerations） 52 附录A RTSP协议状态机 53A.1 客户端状态机 53A.2 服务器端状态机 53附录B 同RTP协议的交互 53附录C 使用SDP进行RTSP会话描述 54C.1 定义 54C.1.1 控制URL 55C.1.2 媒体流 55C.1.3 有效载荷类型 55C.1.4 详细格式参数 55C.1.5 表示的范围 56C.1.6 有效时间 56C.1.7 连接信息 56C.1.8 实体标签 57C.2 合控制不可用 57C.3 合控制可用 57附录D 最简单的RTSP实现 58D.1 客户端 58D.1.1回放 58D.1.2 授权 58D.2 服务器 59D.2.1回放 59D.2.2授权 59附录E 作者地址 60附录F 致谢 60参考书目 60版权申明 611 绪论1.1 目的实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。
Network Working Group T. Hardjono Request for Comments: 3740 Verisign Category: Informational B. Weis Cisco March 2004 The Multicast Group Security ArchitectureStatus 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 (2004). All Rights Reserved.AbstractThis document provides an overview and rationale of the multicastsecurity architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast SecurityReference Framework, and proceeds to identify the security servicesthat may be part of a secure multicast solution.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Summary of Contents of Document. . . . . . . . . . . . . 3 1.3. Audience . . . . . . . . . . . . . . . . . . . . . . . . 41.4. Terminology. . . . . . . . . . . . . . . . . . . . . . . 42. Architectural Design: The Multicast Security ReferenceFramework. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. The Reference Framework. . . . . . . . . . . . . . . . . 4 2.2. Elements of the Centralized Reference Framework. . . . . 5 2.2.1. Group Controller and Key Server. . . . . . . . . 6 2.2.2. Sender and Receiver. . . . . . . . . . . . . . . 7 2.2.3. Policy Server. . . . . . . . . . . . . . . . . . 72.3. Elements of the Distributed Reference Framework. . . . . 83. Functional Areas . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 9 3.2. Group Key Management . . . . . . . . . . . . . . . . . . 103.3. Multicast Security Policies. . . . . . . . . . . . . . . 114. Group Security Associations (GSA). . . . . . . . . . . . . . . 12 4.1. The Security Association . . . . . . . . . . . . . . . . 12 Hardjono & Weis Informational [Page 1]4.2. Structure of a GSA: Introduction . . . . . . . . . . . . 13 4.3. Structure of a GSA: Reasoning. . . . . . . . . . . . . . 14 4.4. Definition of GSA. . . . . . . . . . . . . . . . . . . . 154.5. Typical Compositions of a GSA. . . . . . . . . . . . . . 175. Security Services. . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Multicast Data Confidentiality . . . . . . . . . . . . . 18 5.2. Multicast Source Authentication and Data Integrity . . . 18 5.3. Multicast Group Authentication . . . . . . . . . . . . . 19 5.4. Multicast Group Membership Management. . . . . . . . . . 19 5.5. Multicast Key Management . . . . . . . . . . . . . . . . 205.6. Multicast Policy Management. . . . . . . . . . . . . . . 216. Security Considerations. . . . . . . . . . . . . . . . . . . . 22 6.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 22 6.2. Group Key Management . . . . . . . . . . . . . . . . . . 226.3. Multicast Security Policies. . . . . . . . . . . . . . . 227. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 238. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 238.2. Informative References . . . . . . . . . . . . . . . . . 239. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 2510. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26 1. IntroductionSecuring IP multicast group communication is a complex task thatinvolves many aspects. Consequently, a secure IP multicast protocol suite must have a number of functional areas that address differentaspects of the solution. This document describes those functionalareas and how they are related.1.1. ScopeThis architecture is concerned with the securing of large multicastgroups. Whereas it can also be used for smaller groups, it is notnecessarily the most efficient means. Other architectures (e.g., the Cliques architecture [STW]) can be more efficient for small ad-hocgroup communication.This architecture is "end to end", and does not require multicastrouting protocols (e.g., PIM [RFC2362]) to participate in thisarchitecture. Inappropriate routing may cause denial of service toapplication layer groups conforming to this architecture. Howeverthe routing cannot affect the authenticity or secrecy of group dataor management packets. The multicast routing protocols couldthemselves use this architecture to protect their own multicast andgroup packets. However, this would be independent of any secureapplication layer group.Hardjono & Weis Informational [Page 2]This architecture does not require IP multicast admission controlprotocols (e.g., IGMP [RFC3376], MLD [RFC3019]) to be a part ofsecure multicast groups. As such, a "join" or "leave" operation for a secure group is independent of a "join" or "leave" of an IPmulticast group. For example, the process of joining a secure group requires being authenticated and authorized by a security device,while the process of joining an IP multicast group entails contacting a multicast-aware router. Admission control protocols couldthemselves use this architecture to protect their own multicastpackets. However, this would be independent of any secureapplication layer group.This architecture does not explicitly describe how secure multicastgroups deal with Network Address Translation (NAT) [RFC2663].Multicast routing protocols generally require the source anddestination addresses and ports of an IP multicast packet to remainunchanged. This allows consistent multicast distribution trees to be created throughout the network. If NAT is used in a network, thenthe connectivity of senders and receivers may be adversely affected. This situation is neither improved or degraded as a result ofdeploying this architecture.This architecture does not require the use of reliable mechanisms,for either data or management protocols. The use of reliablemulticast routing techniques (e.g., FEC [RFC3453]) enhance theavailability of secure multicast groups. However the authenticity or secrecy of group data or management packets is not affected by theomission of that capability from a deployment.1.2. Summary of Contents of DocumentThis document provides an architectural overview that outlines thesecurity services required to secure large multicast groups. Itprovides a Reference Framework for organizing the various elementswithin the architecture, and explains the elements of the ReferenceFramework.The Reference Framework organizes the elements of the architecturealong three Functional Areas pertaining to security. These elements cover the treatment of data when it is to be sent to a group, themanagement of keying material used to protect the data, and thepolicies governing a group.Another important item in this document is the definition andexplanation of Group Security Associations (GSA), which is themulticast counterpart of the unicast Security Association (SA). The GSA is specific to multicast security, and is the foundation of thework on group key management.Hardjono & Weis Informational [Page 3]1.3. AudienceThis document is addressed to the technical community, implementersof IP multicast security technology, and others interested in gaining a general background understanding of multicast security. Thisdocument assumes that the reader is familiar with the InternetProtocol, the IPsec suite of protocols (e.g., [RFC2401]), relatednetworking technology, and general security terms and concepts.1.4. TerminologyThe following key terms are used throughout this document.1-to-NA group which has one sender and many receivers.Group Security Association (GSA)A bundling of Security Associations (SAs) that together define how a group communicates securely. The GSA may include a registration protocol SA, a rekey protocol SA, and one or more data securityprotocol SAs.M-to-NA group which has many senders and many receivers, where M and Nare not necessarily the same value.Security Association (SA)A set of policy and cryptographic keys that provide securityservices to network traffic that matches that policy.2. Architectural Design: The Multicast Security Reference FrameworkThis section considers the complex issues of multicast security inthe context of a Reference Framework. This Reference Framework isused to classify functional areas, functional elements, andinterfaces. Two designs of the Reference Framework are shown: acentralized design, and a distributed design that extends thecentralized design for very large groups.2.1. The Reference FrameworkThe Reference Framework is based on three broad functional areas (as shown in Figure 1). The Reference Framework incorporates the mainentities and functions relating to multicast security, and depicts Hardjono & Weis Informational [Page 4]the inter-relations among them. It also expresses multicast security from the perspective of multicast group types (1-to-N and M-to-N),and classes of protocols (the exchanged messages) needed to securemulticast packets.The aim of the Reference Framework is to provide some general context around the functional areas, and the relationships between thefunctional areas. Note that some issues span more than onefunctional area. In fact, the framework encourages the preciseidentification and formulation of issues that involve more than onefunctional area or those which are difficult to express in terms of a single functional area. An example of such a case is the expression of policies concerning group keys, which involves both the functional areas of group key management and multicast policies.When considering the Reference Framework diagrams, it is important to realize that the singular "boxes" in the framework do not necessarily imply a corresponding singular entity implementing a given function. Rather, a box in the framework should be interpreted loosely aspertaining to a given function related to a functional area. Whether that function is in reality implemented as one or more physicalentities is dependent on the particular solution. As an example, the box labeled "Key Server" must be interpreted in broad terms asreferring to the functions of key management.Similarly, the Reference Framework acknowledges that someimplementations may in fact merge a number of the "boxes" into asingle physical entity. This could be true even across functionalareas. For example, an entity in a group could act as both a GroupController and a Sender to a group.The protocols to be standardized are depicted in the ReferenceFramework diagrams by the arrows that connect the various boxes. See more details in Section 4, below.2.2. Elements of the Centralized Reference FrameworkThe Reference Framework diagram of Figure 1 contains boxes andarrows. The boxes are the functional entities and the arrows are the interfaces between them. Standard protocols are needed for theinterfaces, which support the multicast services between thefunctional entities.In some cases, a system implementing the multicast securityarchitecture may not need to implement protocols to account for every interface. Rather, those interfaces may be satisfied through the use of manual configuration, or even omitted if they are not necessaryfor the application.Hardjono & Weis Informational [Page 5]There are three sets of functional entities. Each is discussedbelow.+--------------------------------------+| || || FUNCTIONAL || AREAS || || +------+ || Multicast |Policy| || Security |Server| || Policies +------+ || ^ || | || | || v || +------+ || Group |Group | || Key |Ctrl/ |<---------+ || Management |Key | | || |Server| V || +------+ +--------+ || ^ | | || | |Receiver| || | | | || v +--------+ || +------+ ^ || | | | || Multicast |Sender|----------+ || Data | | || Handling | | || +------+ || |+--------------------------------------+Figure 1: Centralized Multicast Security Reference Framework2.2.1. Group Controller and Key ServerThe Group Controller and Key Server (GCKS) represent both the entity and functions relating to the issuance and management ofcryptographic keys used by a multicast group. The GCKS also conducts user-authentication and authorization checks on the candidate members of the multicast group.Hardjono & Weis Informational [Page 6]The Key Server (KS) and the Group Controller (GC) have somewhatdifferent functionality and may in principle be regarded as separate entities. Currently the framework regards the two entities as one"box" in order to simplify the design, and in order not to mandatestandardization of the protocol between the KS and the GC. It isstressed that the KS and GC need not be co-located. Furthermore,future designs may choose to standardize the protocol between the GC and the KS, without altering other components.2.2.2. Sender and ReceiverThe Sender is an entity that sends data to the multicast group. In a 1-to-N multicast group only a single sender is authorized to transmit data to the group. In an M-to-N multicast group, two or more groupmembers are authorized to be senders. In some groups all members are authorized as senders.Both Sender and Receiver must interact with the GCKS entity for thepurpose of key management. This includes user and/or deviceauthentication, user and/or device authorization, the obtaining ofkeying material in accordance with some key management policies forthe group, obtaining new keys during key-updates, and obtaining other messages relating to the management of keying material and securityparameters.Senders and Receivers may receive much of their policy from the GCKS entities. The event of joining a multicast group is typicallycoupled with the Sender/Receiver obtaining keying material from aGCKS entity. This does not preclude the direct interaction betweenthe Sender/Receiver and the Policy Server.2.2.3. Policy ServerThe Policy Server represents both the entity and functions used tocreate and manage security policies specific to a multicast group.The Policy Server interacts with the GCKS entity in order to install and manage the security policies related to the membership of a given multicast group and those related to keying material for a multicast group.The interactions between the Policy Server and other entities in the Reference Framework is dependent to a large extent on the securitycircumstances being addressed by a given policy.Hardjono & Weis Informational [Page 7]2.3. Elements of the Distributed Reference FrameworkThe need for solutions to be scalable to large groups across widegeographic regions of the Internet requires the elements of theframework to also function as a distributed system. Figure 2 showshow distributed designs supporting large group scalability fit intothe Reference Framework.+-----------------------------------------------------------------+ | | | | | FUNCTIONAL | | AREAS | | +------+ +------+ | | Multicast |Policy|<-------------------------------->|Policy| | | Security |Server| |Server| | | Policies +------+ +------+ | | ^ ^ | | | | | | | | | | v v | | +------+ +------+ | | Group |Group |<-------------------------------> |Group | | | Key |Ctrl/ |<---------+ |Ctlr/ | | | Management |Key | | |Key | | | |Server| V |Server| | | +------+ +--------+ +------+ | | ^ | | ^ | | | |Receiver| | | | | | | | | | v +--------+ | | | +------+ ^ V | | | | | +--------+ | | Multicast |Sender|----------+ | | | | Data | |-------------------------------->|Receiver| | | Handling | | | | | | +------+ +--------+ | +-----------------------------------------------------------------+ Figure 2: Distributed Multicast Security Reference FrameworkIn a distributed design the GCKS entity interacts with other GCKSentities to achieve scalability in the key management relatedservices. GCKS entities will require a means of authenticating their peer GCKS entities, a means of authorization, and a means ofinteracting securely to pass keys and policy.Hardjono & Weis Informational [Page 8]Similarly, Policy Servers must interact with each other securely toallow the communication and enforcement of policies across theInternet.Two Receiver boxes are displayed corresponding to the situation where both the Sender and Receiver employ the same GCKS entity (centralized architecture) and where the Sender and Receiver employ different GCKS entities (distributed architecture). In the distributed design, all Receivers must obtain identical keys and policy. Each member of amulticast group may interact with a primary GCKS entity (e.g., the"nearest" GCKS entity, measured in terms of a well-defined andconsistent metric). Similarly, a GCKS entity may interact with oneor more Policy Servers, also arranged in a distributed architecture.3. Functional AreasThe Reference Framework identifies three functional areas. They are: - Multicast data handling. This area covers the security-related treatments of multicast data by the sender and the receiver.This functional area is further discussed in Section 3.1.- Group Key Management. This area is concerned with the securedistribution and refreshment of keying material. Thisfunctional area is further discussed in Section 3.2.- Multicast Security Policies. This area covers aspects ofpolicy in the context of multicast security, taking intoconsideration the fact that policies may be expressed indifferent ways: that they may exist at different levels in agiven multicast security architecture, and that they may beinterpreted differently according to the context in which they are specified and implemented. This functional area is further discussed in Section 3.3.3.1. Multicast Data HandlingIn a secure multicast group, the data typically needs to be:1. Encrypted using the group key, mainly for access control andpossibly also for confidentiality.2. Authenticated, for verifying the source and integrity of thedata. Authentication takes two flavors:a. Source authentication and data integrity. Thisfunctionality guarantees that the data originated with theclaimed source and was not modified en route (either by agroup member or an external attacker).Hardjono & Weis Informational [Page 9]b. Group authentication. This type of authentication onlyguarantees that the data was generated (or last modified) by some group member. It does not guarantee data integrityunless all group members are trusted.While multicast encryption and group authentication are fairlystandard and similar to encrypting and authenticating a point-to-point communication, source authentication for multicast isconsiderably more involved. Consequently, off-the-shelf solutions(e.g., taken from IPsec [RFC2406]) may be sufficient for encryptionand group authentication. For source authentication, however,special-purpose transformations are necessary. See [CCPRRS] forfurther elaboration on the concerns regarding the data transforms.Multicast data encrypted and/or authenticated by a sender should behandled the same way by both centralized and distributed receivers,(as shown in Figure 2).The "Multicast Encapsulating Security Payload" [BCCR] provides thedefinition for Multicast ESP for data traffic. The "Multicast Source Authentication Transform Specification" [PCW] defines the use of the TESLA algorithm for source authentication in multicast.3.2. Group Key ManagementThe term "keying material" refers to the cryptographic keys belonging to a group, the state associated with the keys, and the othersecurity parameters related to the keys. Hence, the management ofthe cryptographic keys belonging to a group necessarily requires the management of their associated state and parameters. A number ofsolutions for specific issues must be addressed. These may includethe following:- Methods for member identification and authentication.- Methods to verify the membership to groups.- Methods to establish a secure channel between a GCKS entity andthe member, for the purpose of delivery of shorter-term keyingmaterial pertaining to a group.- Methods to establish a long-term secure channel between one GCKSentity and another, for the purpose of distributing shorter-termkeying material pertaining to a group.- Methods to effect the changing of keys and keying material.- Methods to detect and signal failures and perceived compromises to keys and keying material.The requirements related to the management of keying material must be seen in the context of the policies that prevail within the givencircumstance.Hardjono & Weis Informational [Page 10]Core to the area of key management is Security Association (SA)Management, which will be discussed further below.A "Group Key Management Architecture" document [BCDL] further defines the key management architecture for multicast security. It builds on the Group Security Association (GSA) concept, and further defines the roles of the Key Server and Group Controller."The Group Domain of Interpretation" [RFC3547], "GSAKMP" [GSAKMP],and "MIKEY" [ACLNM] are three instances of protocols implementing the group key management function.3.3. Multicast Security PoliciesMulticast Security Policies must provide the rules for operation for the other elements of the Reference Framework. Security Policies may be distributed in an ad-hoc fashion in some instances. However,better coordination and higher levels of assurance are achieved if a Policy Controller distributes Security Policies policy to the group. Multicast security policies must represent, or contain, moreinformation than a traditional peer-to-peer policy. In addition torepresenting the security mechanisms for the group communication, the policy must also represent the rules for the governance of the secure group. For example, policy would specify the authorization levelnecessary in order for an entity to join a group. More advancedoperations would include the conditions when a group member must beforcibly removed from the group, and what to do if the group members need to resynchronize because of lost key management messages.The application of policy at the Group Controller element and themember (sender and receiver) elements must be described. While there is already a basis for security policy management in the IETF,multicast security policy management extends the concepts developedfor unicast communication in the areas of:- Policy creation,- High-level policy translation, and- Policy representation.Examples of work in multicast security policies include the DynamicCryptographic Context Management project [Din], Group Key Management Protocol [Har1, Har2], and Antigone [McD].Policy creation for secure multicast has several more dimensions than the single administrator specified policy assumed in the existingunicast policy frameworks. Secure multicast groups are usually large and by their very nature extend over several administrative domains, Hardjono & Weis Informational [Page 11]if not spanning a different domain for each user. There are several methods that need to be considered in the creation of a single,coherent group security policy. They include a top-downspecification of the group policy from the group initiator andnegotiation of the policy between the group members (or prospectivemembers). Negotiation can be as simple as a strict intersection ofthe policies of the members or extremely complicated using weightedvoting systems.The translation of policy rules from one data model to another ismuch more difficult in a multicast group environment. This isespecially true when group membership spans multiple administrativedomains. Policies specified at a high level with a Policy Management tool must be translated into more precise rules that the availablesecurity policy mechanisms can both understand and implement. Whendealing with multicast communication and its multiple participants,it is essential that the individual translation performed for eachparticipant result in the use of a mechanism that is interoperablewith the results of all of the other translations. Typically, thetranslation from high-level policy to specific policy objects mustresult in the same objects in order to achieve communication between all of the group members. The requirement that policy translationresults in the same objects places constraints on the use andrepresentations in the high-level policies.It is also important that policy negotiation and translation beperformed as an integral part of joining a group. Adding a member to a group is meaningless if they will not be able to participate in the group communications.4. Group Security Associations (GSA)4.1. The Security AssociationA security association is a commonly used term in cryptographicsystems (e.g., [RFC2401, RFC2406bis, RFC2409]). This document usesthe term to mean any set of policy and cryptographic keys thatprovide security services for the network traffic matching thatpolicy. A Security Association usually contains the followingattributes:- selectors, such as source and destination transport addresses. - properties, such as an security parameter index (SPI) or cookie pair, and identities.- cryptographic policy, such as the algorithms, modes, keylifetimes, and key lengths used for authentication orconfidentiality.- keys, such as authentication, encryption and signing keys. Hardjono & Weis Informational [Page 12]Group key management uses a different set of abstractions thanpoint-to-point key management systems (such as IKE [RFC2409]).Notwithstanding, the abstractions used in the Group Key Managementfunctional area may be built from the point-to-point key managementabstractions.4.2. Structure of a GSA: IntroductionSecurity associations (SAs) for group key management are morecomplex, and are usually more numerous, than for point-to-point keymanagement algorithms. The latter establishes a key management SA to protect application SAs (usually one or two, depending on theprotocol). However, group key management may require up to three or more SAs. These SAs are described in later sections.A GSA contains all of the SA attributes identified in the previoussection, as well some additional attributes pertaining to the group. As shown in Figure 3, the GSA builds on the SA in two distinct ways. - First, the GSA is a superset of an SA (Figure 3(a)). A GSA hasgroup policy attributes. For example, the kind of signedcredentials needed for group membership, whether group memberswill be given new keys when a member is added (called "backwardre-key" below), or whether group members will be given new keyswhen a member is removed from the group ("forward re-key"). A GSA also includes an SA as an attribute of itself.- Second, the GSA is an aggregation of SAs (Figure 3(b)). A GSA is comprised of multiple SAs, and these SAs may be used for severalindependent purposes.+---------------+ +-------------------+| GSA | | GSA || | | +-----+ +-----+ || | | | SA1 | | SA2 | || +----+ | | +-----+ +-----+ || | SA | | | +-----+ || +----+ | | | SA3 | || | | +-----+ |+---------------+ +-------------------+(a) superset (b) aggregationFigure 3: Relationship of GSA to SAHardjono & Weis Informational [Page 13]。
