CAN CSA-ISO IEC 9798-3A-2012 Information technology Security techniques Entity authentication Part 3 Mechanisms using digital signature techniques AMENDMENT 1.pdf

《CAN CSA-ISO IEC 9798-3A-2012 Information technology Security techniques Entity authentication Part 3 Mechanisms using digital signature techniques AMENDMENT 1.pdf》由会员分享，可在线阅读，更多相关《CAN CSA-ISO IEC 9798-3A-2012 Information technology Security techniques Entity authentication Part 3 Mechanisms using digital signature techniques AMENDMENT 1.pdf（16页珍藏版）》请在麦多课文档分享上搜索。

1、Information technology Secu rity techniques Entity authentication Part 3: Mech anisms using digital signature techniques AMENDMENT 1Amendment 1:2012 (IDT) toNational Standard of CanadaCAN/CSA-ISO/IEC 9798-3-02(ISO/IEC 9798-3:1998, IDT)NOT FOR RESALE.PUBLICATION NON DESTINE LA REVENTE.CSA Standards U

2、pdate ServiceAmendment 1:2012 toCAN/CSA-ISO/IEC 9798-3-02March 2012Title:Information technology Secu rity techniques Entity authentication Part 3: Mechanisms using digital signature techniques AMENDMENT 1Pagination:11 pages (iii preliminary and 8 text)To register for e-mail notification about any up

3、dates to this publication go on-line to shop.csa.caclick on E-mail Services under MY ACCOUNTclick on CSA Standards Update ServiceThe List ID that you will need to register for updates to this publication is 2415776.If you require assistance, please e-mail techsupportcsa.ca or call 416-747-2233.Visit

4、 CSAs policy on privacy at csagroup.org/legal to find out how we protect your personal information.Reference numberISO/IEC 9798-3:1998/Amd.1:2010(E)ISO/IEC 2010INTERNATIONAL STANDARD ISO/IEC9798-3Second edition1998-10-15AMENDMENT 12010-06-01Information technology Security techniques Entity authentic

5、ation Part 3: Mechanisms using digital signature techniques AMENDMENT 1 Technologies de linformation Techniques de scurit Authentification dentit Partie 3: Mcanismes utilisant des techniques de signature numriquesAMENDEMENT 1 ISO/IEC 9798-3:1998/Amd.1:2010(E) PDF disclaimer This PDF file may contain

6、 embedded typefaces. In accordance with Adobes licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this file, parties accept therein the responsibilit

7、y of not infringing Adobes licensing policy. The ISO Central Secretariat accepts no liability in this area. Adobe is a trademark of Adobe Systems Incorporated. Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parame

8、ters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below. COPYRIGHT PROTECTED DOCUMENT ISO/IEC 2010 All

9、rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISOs member body in the country of

10、 the requester. ISO copyright office Case postale 56 CH-1211 Geneva 20 Tel. + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.org Web www.iso.org ii ISO/IEC 2010 All rights reservedISO/IEC 9798-3:1998/Amd.1:2010(E) ISO/IEC 2010 All rights reserved iiiForeword ISO (the International Organiz

11、ation for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respe

12、ctive organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of informati

13、on technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of the joint technical committee is to prepare International Standards. Draft International

14、Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. Attention is drawn to the possibility that some of the elements of this document may be

15、the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Amendment 1 to ISO/IEC 9798-3:1998 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 27, IT Security techniques. Amendment 1:2012 to C

16、AN/CSA-ISO/IEC 9798-3-02ISO/IEC 9798-3:1998/Amd.1:2010(E) ISO/IEC 2010 All rights reserved 1Information technology Security techniques Entity authentication Part 3: Mechanisms using digital signature techniques AMENDMENT 1 Page 1, Clause 3 Replace the first paragraph of Clause 3 with the following:

17、For the purposes of this part of ISO/IEC 9798, the definitions and notation described in ISO/IEC 9798-1 and the following apply: IAThe identity of entity A, which is either A or CertA. IBThe identity of entity B, which is either B or CertB. ResX The result of verifying entity Xs public key or public

18、 key certificate. Page 5, 5.2.3 Add the following after 5.2.3: 6 Mechanisms involving an on-line trusted third party 6.1 Introduction The authentication mechanisms in this clause require the two entities A and B to validate each others public keys using an on-line trusted third party (with distingui

19、shing identifier TP). This trusted third party shall possess reliable copies of the public keys of A and B. The entities A and B shall possess a reliable copy of the public key of TP. This clause specifies two five pass authentication mechanisms, both of which achieve mutual authentication between e

20、ntities A and B. In the specification of the two mechanisms, the form of tokens and text fields follow the description given at the beginning of Clause 5, i.e. all paragraphs in Clause 5 before 5.1. Implementations of the mechanisms shall use one of the signature schemes specified in ISO/IEC 14888 o

21、r ISO/IEC 9796. Amendment 1:2012 to CAN/CSA-ISO/IEC 9798-3-02ISO/IEC 9798-3:1998/Amd.1:2010(E) 2 ISO/IEC 2010 All rights reserved6.2 Five pass authentication (initiated by A) In this authentication mechanism, uniqueness/timeliness is controlled by generating and checking a random number (see Annex B

22、 of ISO/IEC 9798-1:1997). This authentication mechanism is illustrated in Figure 6. Figure 6 Five pass authentication (initiated by A) The tokens shall be created according to one of the following two options. Option 1: TokenAB = Text9|ResA|sST(RB|ResA|Text5)|sSA(RB|RA|B|A|Text8)TokenBA = RA|RB|Text

23、3|sSB(B|RA|RB|A|Text2) TokenTA = ResA|ResB|sST(RA|ResB|Text6)|sST(RB|ResA|Text5) Option 2: TokenAB = RA|Text9|TokenTA|sSA(RB|RA|B|A|Text8) TokenBA = RA|RB|Text3|sSB(B|RA|RB|A|Text2) TokenTA = ResA|ResB|sST(RA|RB|ResA|ResB|Text5) The values of the fields IA, IB, ResA, ResB, Status and Failure shall h

24、ave the following forms: IA= A or CertA IB= B or CertB ResA = (CertA|Status), (A|PA) or Failure ResB = (CertB|Status), (B|PB) or Failure TP A B (1) RA|IA|Text1(2) IB|TokenBA(3) RA|RB|IA|IB|Text4(5) Text7|TokenTA (7) TokenAB(4) (6) (8) Amendment 1:2012 to CAN/CSA-ISO/IEC 9798-3-02ISO/IEC 9798-3:1998/

25、Amd.1:2010(E) ISO/IEC 2010 All rights reserved 3Status = True or False. The value of the field shall be set to False if the certificate is known to have been revoked; otherwise it shall be set to True. Failure: ResX (where X = A, B) will be set to Failure if neither a public key nor a certificate of

26、 entity X can be found by TP. In the mechanism, if TP knows the mapping between identity X and PX(where X = A, B), then it shall set IX= X; otherwise, it shall set IX= CertX, and X shall be set equal to the collection of distinguished identity fields in CertX. If either X or CertX is permitted to be

27、 used as an identity, then there should be a pre-arranged means to allow TP to distinguish the two types of identity indications. The value of ResX (where X = A, B) shall be determined according to Table 1. Table 1 Value of ResX Field Choice 1 Choice 2 IXX CertX ResX (X|PX ) or Failure (CertX|Status

28、) or Failure The mechanism is performed as follows: 1) A sends a random number RA, its identity IAand, optionally, a text field Text1 to B. 2) B sends the token TokenBA and IBto A. 3) A sends a random number RA, together with RB, IA, IBand, optionally, a text field Text4 to TP. 4) On receipt of the

29、message in Step (3) from A, TP performs the following steps. If IA= A and IB= B, TP retrieves PAand PB; If IA= CertA and IB= CertB, TP checks the validity of CertA and CertB. The process of certificate verification by TP may require protection from denial-of-service attacks. The specification of mec

30、hanisms to be used to provide such protection is outside of the scope of this part of ISO/IEC 9798. 5) Then TP sends TokenTA and, optionally, a text field Text7 to A. The fields ResA and ResB in TokenTA shall be: the certificates of A and B and their status, the distinguishing identifiers of A and B

31、 and their public keys, or an indication of Failure. 6) On receipt of the message in Step (5) from TP, A performs the following steps: (i) Verify TokenTA by checking the signature of TP contained in the token, and by checking that the random number RA, sent to TP in Step (3), is the same as the rand

32、om number RA contained in the signed data of TokenTA. (ii) Retrieve the public key of B from the message, verify TokenBA received in Step (2) by checking the signature of B contained in the token and checking that the value of identifier field (A) in the signed data of TokenBA is equal to As disting

33、uishing identifier, and then check that the random number RA, sent to B in Step (1), is the same as the random number RAcontained in TokenBA. 7) A sends TokenAB to B. 8) On receipt of the message in Step (7) from A, B performs the following steps: (i) Verify TokenTA by checking the signature of TP c

34、ontained in the token, and by checking that the random number RB, sent to A in Step (2), is the same as the random number RBcontained in the signed data of TokenTA. Amendment 1:2012 to CAN/CSA-ISO/IEC 9798-3-02ISO/IEC 9798-3:1998/Amd.1:2010(E) 4 ISO/IEC 2010 All rights reserved(ii) Retrieve the publ

35、ic key of A from the message, verify TokenAB by checking the signature of A contained in the token and checking that the value of identifier field (B) in the signed data of TokenAB is equal to Bs distinguishing identifier, and then check that the random number RBcontained in the signed data of Token

36、AB is equal to the random number RBsent to A in Step (2). 6.3 Five pass authentication (initiated by B) In this authentication mechanism, uniqueness/timeliness is controlled by generating and checking a random number (see Annex B of ISO/IEC 9798-1). This authentication mechanism is illustrated in Fi

37、gure 7. Figure 7 Five pass authentication (initiated by B) The tokens shall be created according to one of the following two options. Option 1: TokenAB = Text7|RA|ResA|sST(RB|ResA|Text3)|sSA(RB|RA|B|A|Text6) TokenBA = RA|RB|Text9|sSB(A|RA|RB|B|Text8) TokenTA = ResA|ResB|sST(RA|ResB|Text4)|sST(RB|Res

38、A|Text3) Option 2: TokenAB = RA|Text7|TokenTA|sSA(RB|RA|B|A|Text6) TokenBA = RA|RB|Text9|sSB(RA|RB|A|B|Text8) TokenTA = ResA|ResB|sST(RA|RB|ResA|ResB|Text3) The values of the fields IA, IB, ResA, ResB, Status and Failure shall have the following forms: IA= A or CertA TP A B (1) RB|IB|Text1(5) IA|Tok

39、enAB(2) RA|RB|IA|IB|Text2(4) Text5|TokenTA (7) TokenBA(3) (8) (6) Amendment 1:2012 to CAN/CSA-ISO/IEC 9798-3-02ISO/IEC 9798-3:1998/Amd.1:2010(E) ISO/IEC 2010 All rights reserved 5IB= B or CertB ResA = (CertA|Status), (A|PA) or Failure ResB = (CertB|Status), (B|PB) or Failure Status = True or False.

40、The value of the field shall be set to False if the certificate is known to have been revoked; otherwise it shall be set to True. Failure: ResY (where Y = A, B) will be set to Failure if neither a public key nor a certificate of entity Y can be found by TP. In the mechanism, if TP knows the mapping

41、between identity Y and PY(where Y = A, B), then it shall set IY= Y; otherwise, it shall set IY= CertY, and Y shall be set equal to the collection of distinguished identity fields in CertY. If either Y or CertY is permitted to be used as an identity, then there should be a pre-arranged means to allow

42、 TP to distinguish the two types of identity indications. The value of ResY (where Y = A, B) shall be determined according to Table 2. Table 2 Value of ResY Field Choice 1 Choice 2 IYY CertY ResY (Y|PY) or Failure (CertY|Status) or Failure The mechanism is performed as follows: 1) B sends a random n

43、umber RB, its identity IBand, optionally, a text field Text1 to A. 2) A sends a random number RA, together with RB, IA, IBand, optionally, a text field Text2 to TP. 3) On receipt of the message in Step (2) from A, TP performs the following steps. If IA= A and IB= B, TP retrieves PAand PB; If IA= Cer

44、tA and IB= CertB, TP checks the validity of CertA and CertB. The process of certificate verification by TP may require protection from denial-of-service attacks. The specification of mechanisms to be used to provide such protection is outside of the scope of this part of ISO/IEC 9798. 4) Then TP sen

45、ds TokenTA and, optionally, a text field Text5 to A. The fields ResA and ResB in TokenTA shall be: the certificates of A and B and their status, the distinguishing identifiers of A and B and their public keys or an indication of Failure. 5) A sends the token TokenAB and IAto B. 6) On receipt of the

46、message in Step (5) from A, B performs the following steps: (i) Verify the signature of TP in TokenAB by checking the signature of TP contained in the token, and by checking that the random number RB, sent to A in Step (1), is the same as the random number RB contained in the signed data of TP of To

47、kenAB. (ii) Retrieve the public key of A from the message, verify TokenAB by checking the signature of A contained in the token and checking that the value of identifier field (B) in the signed data of TokenAB is equal to Bs distinguishing identifier, and then check that the random number RB, sent t

48、o A in Step (1), is the same as the random number RBcontained in the signed data of A of TokenAB. 7) B sends TokenBA to A. Amendment 1:2012 to CAN/CSA-ISO/IEC 9798-3-02ISO/IEC 9798-3:1998/Amd.1:2010(E) 6 ISO/IEC 2010 All rights reserved8) On receipt of the message in Step (7) from B, A performs the

49、following steps: (i) Verify TokenTA by checking the signature of TP contained in the token, and by checking that the random number RA, sent to TP in Step (2), is the same as the random number RAcontained in the signed data of TokenTA. (ii) Retrieve the public key of B from the message, verify TokenBA by checking the signature of B contained in the token