ETSI EN 301 261-3 V1.2.1 (1999-01)

Telecommunications Management Network (TMN); Security; Part 3: Security services; Authentication of users and entities in a TMN environment

DEN/TMN-00002-3

Telekomunikacijsko upravljavno omrežje (TMN) - Varnost - 3. del: Varnostne storitve - Avtentikacija uporabnikov in osebkov v okolju TMN

General Information

• Status: Published
• Publication Date: 20-Jan-1999
• Technical Committee: TMN - Telecommunications Management Network
• Current Stage: 12 - Completion
• Due Date: 01-Jan-1999
• Completion Date: 21-Jan-1999
• Ref Project: SIST EN 301 261-3 V1.2.1:2003 - Telecommunications Management Network (TMN); Security; Part 3: Security services; Authentication of users and entities in a TMN environment

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Telekomunikacijsko upravljavno omrežje (TMN) - Varnost - 3. del: Varnostne storitve - Avtentikacija uporabnikov in osebkov v okolju TMNTelecommunications Management Network (TMN); Security; Part 3: Security services; Authentication of users and entities in a TMN environment33.040.35Telefonska omrežjaTelephone networksICS:Ta slovenski standard je istoveten z:EN 301 261-3 Version 1.2.1SIST EN 301 261-3 V1.2.1:2003en01-november-2003SIST EN 301 261-3 V1.2.1:2003SLOVENSKI
STANDARD



SIST EN 301 261-3 V1.2.1:2003



EN 301 261-3 V1.2.1 (1999-01)European Standard (Telecommunications series)Telecommunications Management Network (TMN);Security;Part 3: Security services;Authentication of users and entities in a TMN environmentSIST EN 301 261-3 V1.2.1:2003



ETSIEN 301 261-3 V1.2.1 (1999-01)2ReferenceDEN/TMN-00002-3 (bocr0ioo.PDF)KeywordsTMN, securityETSIPostal addressF-06921 Sophia Antipolis Cedex - FRANCEOffice address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: [phone]
Fax: [phone]Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/[e-mail] copies of this ETSI deliverablecan be downloaded fromhttp://www.etsi.orgIf you find errors in the present document, send yourcomment to: [e-mail] NotificationNo part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute 1999.All rights reserved.SIST EN 301 261-3 V1.2.1:2003



ETSIEN 301 261-3 V1.2.1 (1999-01)3ContentsIntellectual Property Rights.5Foreword.5Introduction.51Scope.72References.72.1Normative references.72.2Informative references.83Definitions and abbreviations.93.1Definitions.93.2Abbreviations.94Architectural aspects.104.1General authentication model.104.2Mapping the authentication model onto TMN.115Authentication services.135.1Human user authentication.135.2Peer-to-peer entity authentication.135.3Data origin authentication.146Authentication mechanisms.146.1Authentication mechanisms using passwords.156.1.1Unilateral authentication.156.1.2Mutual authentication.156.2Authentication mechanisms based on secret keys.166.2.1Unilateral authentication.166.2.2Mutual authentication.166.3Authentication mechanisms based on public keys.176.3.1Unilateral authentication.176.3.2Mutual authentication.177Communication protocol mapping.177.1Human user authentication.177.2Peer-to-peer entity authentication.187.2.1General Procedure.187.2.2Specification of the authentication information syntax in ACSE.198Authentication parameter negotiation.22Annex A (informative):Relationship to GSS-API.23A.1Introduction to GSS-API.23A.2Relationship between GSS-API and authentication.23A.3GSS-API mechanisms supported by the present document.23A.4Communication protocol mapping.24Annex B (informative):Algorithms.25B.1Hash functions.25B.2Symmetric encipherment algorithms.25B.3Public key algorithms.25SIST EN 301 261-3 V1.2.1:2003



ETSIEN 301 261-3 V1.2.1 (1999-01)4Annex C (informative):Partial PICS for ACSE authentication information.26C.1Unilateral authentication parameter support.26C.1.1Sending (AARQ PDU).26C.1.2Receiving (AARQ PDU).26C.2Mutual authentication parameter support.26C.2.1Sending (AARQ PDU).26C.2.2Receiving (AARQ PDU).26C.2.3Sending (AARE PDU).26C.2.4Receiving (AARE PDU).27Annex D (informative):Combined use of the present document and
ITU-TRecommendation Q.813.28D.1Use of the ITU-T Recommendation Q.813 peer entity authentication.28D.2Use of an EN authenticator in combination with a protected ROSE PDU.28Annex E (informative):Bibliography.29History.30SIST EN 301 261-3 V1.2.1:2003



ETSIEN 301 261-3 V1.2.1 (1999-01)5Intellectual Property RightsIPRs essential or potentially essential to the present document may have been declared to ETSI. The informationpertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be foundin SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respectof ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on theETSI Web server (http://www.etsi.org/ipr).Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guaranteecan be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server)which are, or may be, or may become, essential to the present document.ForewordThis European Standard (Telecommunications series) has been produced by ETSI Technical CommitteeTelecommunications Management Network (TMN).The present document is part 3 of a multi-part EN covering security, as identified below:Part 1:"Framework";Part 2:"Security support services and security management";Part 3:"Security services; Authentication of users and entities in a TMN environment";Part 4:"Security services; Access control".National transposition datesDate of adoption of this EN:18 December 1998Date of latest announcement of this EN (doa):31 March 1999Date of latest publication of new National Standardor endorsement of this EN (dop/e):30 September 1999Date of withdrawal of any conflicting National Standard (dow):30 September 1999IntroductionThe authentication service ensures that the identities of the calling and called parties are indeed genuine, that is, they arewho they claim they are. Authentication is a first step in establishing secure communications between the calling andcalled parties.The verification of an identity can be ascertained only for the instant of the authentication exchange. To guarantee theidentity of a communication party for subsequent communication data, the authentication exchange must be usedcombined with a secure means of communication (e.g. an integrity service).Authentication is also a support service for many other security services such as e.g. secure exchange of secret keysbetween calling and called parties.The authentication service is one of the TMN security services. A complete overview about all TMN security servicesand the relationships between security services will be given in a framework document.SIST EN 301 261-3 V1.2.1:2003



ETSIEN 301 261-3 V1.2.1 (1999-01)6Prerequisites for the use of the described authentication service (as well as for the use of other TMN security services)are:-the availability of security support services (like key management etc.);-the availability of management features for the authentication service; and-the availability of management features for the security support services.These prerequisites are described in separate documents.The relationship between the present document and the GSS-API (Generic Security Service Application ProgramInterface, see IETF RFC 2078 [19]) is described in annex A.The combined use of the present document and ITU-T Recommendation Q.813 [12] is given in annex D.SIST EN 301 261-3 V1.2.1:2003



ETSIEN 301 261-3 V1.2.1 (1999-01)71ScopeThe present document specifies the authentication service for all kind of users involved in a TMN. Normally, one candistinguish between three types of authentication: (human) user authentication, peer-to-peer entity authentication anddata origin authentication. The main scope of the present document is peer-to-peer entity authentication, even if humanuser authentication is also partly addressed. Data origin authentication will not be addressed as an explicit TMNauthentication service for reasons described later in the present document.The authentication service shall be realized by employing one of a set of various security mechanisms based onpassword and/or cryptographic means. The main focus of the present document is the description of securitymechanisms for peer entity authentication even if these mechanisms may also be applicable for human userauthentication. Authentication mechanisms, that may be applicable only for human user authentication, are outside thescope of the present document.The content of the present document is applicable to communication between any two TMN system entities (e.g.Operations System (OS) and Network Element (NE)) that communicates via a TMN Q3-or an X-interface. The presentdocument addresses peer-to-peer entity authentication at the OSI application layer (layer 7) through the use of ACSE. Itdoes not attempt to cover authentication schemes that may be appropriate for lower OSI layers or other protocol stacks.This does not necessarily restrict the usability of the described authentication services (or part of them) at lower OSIlayers or with other protocol stacks.To the extent that human user authentication is covered, it will be related to the TMN F-interface.The present document does not describe the relationships between authentication service and other security services, thefeatures for managing the authentication service and the authentication support services.2ReferencesReferences may be made to:a)specific versions of publications (identified by date of publication, edition number, version number, etc.), inwhich case, subsequent revisions to the referenced document do not apply; orb)all versions up to and including the identified version (identified by "up to and including" before the versionidentity); orc)all versions subsequent to and including the identified version (identified by "onwards" following the versionidentity); ord)publications without mention of a specific version, in which case the latest version applies.A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the samenumber.2.1Normative references[1]ITU-T Recommendation X.509 | ISO 9594-8: "Information technology - Open SystemsInterconnection - The Directory: Authentication framework".[2]ITU-T Recommendation X.511 | ISO 9594-3: "Information technology - Open SystemsInterconnection -The Directory: Abstract service definition".[3]ISO/IEC 9798-1: "Information technology - Security techniques -Entity authenticationmechanisms - Part 1: General".[4]ISO/IEC 9798-2: "Information technology - Security techniques -Entity authentication -Part 2: Mechanisms using symmetric encipherment algorithms".SIST EN 301 261-3 V1.2.1:2003



ETSIEN 301 261-3 V1.2.1 (1999-01)8[5]ISO/IEC 9798-3: "Information technology - Security techniques - Entity authenticationmechanisms - Part 3: Entity authentication using a public key algorithm".[6]ITU-T Recommendation X.227 | ISO/IEC 8650-1: "Information technology - Open SystemsInterconnection – Connection-oriented protocol for the association control service element:Protocol specification".[7]ITU-T Recommendation X.227 AM1 | ISO/IEC 8650 AM1:Series X: "Incorporation ofextensibility markers".[8]ITU-T Recommendation X.702 | ISO 11587: "Information technology - Open SystemsInterconnection - Application context for systems management with transaction processing".[9]ITU-T Recommendation X.501: "Information technology - Open Systems Interconnection - TheDirectory: Models".[10]ISO/IEC 9797: "Information technology, Security techniques - Data integrity mechanism using acryptographic check function employing a block cipher algorithm".[11]ISO/IEC 10183-3: "Hash Functions - Part 3: Dedicated Hash Functions".[12]ITU-T Recommendation Q.813: "Security Transformations Application Service Element forRemote Operations Service Element (STASE-ROSE)".NOTE:ITU-T Recommendation Q.813 will be published shortly.2.2Informative references[13]NMF Application Services - Security of Management, Issue 1, 9/92.[14]IETF RFC 1321: "The MD5 Message Digest Algorithm".[15]FIPSPUB 188: "Standard Security Label for Information Transfer".[16]FIPS PUB 46-2: "Data Encryption Standard (DES)".[17]FIPS PUB 186: "Digital Signature Standard (DSA)".[18]ATM Forum: "ATM Security Specification Version 1.0, STR-SEC-01.01 (Straw Ballot)".[19]IETF RFC 2078: "Generic Security Service Application Program Interface Version 2".[20]IETF RFC 2025: "The Simple Public-key GSS-API Mechanism (SPKM)".[21]IETF RFC 1964: "The Kerberos Version 5 GSS-API Mechanism".[22]Lai On the design and security of block ciphers, ETH Series in Information Processing, J.L.Massey(editor), vol. 1, Hartung-Gorre Verlag Konstanz, ETH Zurich, 1992.[23]Public Key Cryptography Standard #1 (PKCS #1): "RSA Encryption Standard, RSA Laboratories,Version 1.5".[24]IETF RFC 2104 HMAC: "Keyed-Hashing for Message Authentication", 2/1997.SIST EN 301 261-3 V1.2.1:2003



ETSIEN 301 261-3 V1.2.1 (1999-01)93Definitions and abbreviations3.1DefinitionsThe following terms are defined in ITU-T Recommendation X.509 | ISO 9594-8 [1]:authentication token, token: see [1].certificate, user certificate: see [1].certification authority: see [1].cryptosystem, cryptographic system: see [1].hash function: see [1].one-way function: see [1].public key: see [1].private key, secret key: see [1].simple authentication: see [1].strong authentication: see [1].trust: see [1].The following terms are defined in ISO/IEC 9798-1 [3]:authentication initiator: see [3].authentication responder: see [3].claimant: see [3].exchange authentication information: see [3].time variant parameter: see [3].token: see [3].trusted third party: see [3].verification authentication information: see [3].verifier: see [3].3.2AbbreviationsFor the purposes of the present document, the following abbreviations apply:ACSEAssociation Control Service ElementATMAsynchronous Transfer ModeCMIPCommon Management Information ProtocolDESData Encryption StandardDSADigital Signature AlgorithmENEuropean Standard (Telecommunications series)FIPSFederal Information Processing StandardFTAMFile Transfer Access MethodGSS-APIGeneric Security Service Application Programming InterfaceSIST EN 301 261-3 V1.2.1:2003



ETSIEN 301 261-3 V1.2.1 (1999-01)10HMACHashed Message Authentication CodeIDEAInternational Data Encryption AlgorithmIETFInternet Engineering Task ForceISOInternational Organization for StandardizationITUInternational Telecommunication UnionMD5Message Digest Algorithm No. 5MFMediation FunctionNENetwork ElementNMFNetwork Management ForumOSOperations SystemOSIOpen Systems InterconnectionPDUProtocol Data UnitPKCSPublic Key Cryptography StandardPUBPublicationRACEResearch and Development Program for Advanced Communications in EuropeRFCRequest for CommentsROSERemote Operations Service ElementRSARivest, Shamir, Aleman (Algorithm)SHASecure Hash AlgorithmSTASESecurity Transformation Application Service ElementTMN Telecommunications Management NetworkWSFWorkstation Function4Architectural aspectsThe authentication service can be used for intradomain and interdomain TMN (for details see part 1 of " Security forTMN"). The authentication service has two facets:-generate an authentication token and to transmit it to another communication partner (claimant facet);-verify an authentication token forwarded by a communication partner (verifier facet).4.1General authentication modelAs described in [3], the general authentication model involves a calling party, a called party and, if necessary, anauthentication party.If a calling party or a called party interact with an authentication party, then they shall trust the authentication party. Theauthentication party is a function that can be for example realized as a domain-internal unit (often called CertificationAuthority) or as part of a TTP (that could be used to settle legal disputes between different domains or legal parties).The authentication party should only be used for the following tasks:-generation of (some) authentication information; and/or-verification of (some) authentication information.The authentication party should not be used for the (direct) communication of the authentication token between callingand called party.It is not essential that the authentication party and all the communication exchanges are present in every authenticationmechanism. In figure 1, the lines indicate potential information flow. The calling respective called party may eitherdirectly or indirectly interact with the authentication party, or use some information issued by the authentication party.SIST EN 301 261-3 V1.2.1:2003



ETSIEN 301 261-3 V1.2.1 (1999-01)11callingpartycalledpartyauthenticationpartyFigure 1: General authentication model4.2Mapping the authentication model onto TMNDependent on the size of a TMN and on the type of assurance required, different architectures can make sense.In some cases, it is efficient to realize the authentication service as part of each TMN component. In these cases, noauthentication party needs to be involved in authentication. The calling party will generate the authenticationinformation. The authentication information will be transmitted to the called party via the OSI protocol stack. The calledparty should verify the authentication information and possibly generate new authentication information. This newauthentication information will be transmitted from the called party to the calling party as part of the response.Claimantcallingpartycalled party(1)
Requestwith Authentication InformationVerifierno specialserver forauthentication(2) Response, possibly with authentication InformationFigure 2: Authentication flow without an authentication partyCurrently, the existing Association Control Service Element (ACSE) only allows a single authentication transfer fromthe calling to the called party and a reply from the called party to the calling party. Therefore, in the present documentno authentication mechanism will be considered, which involves more than two information exchanges between callingand called party.In some TMN environments (e.g. a TMN environment containing many operations systems), it can be advantageous toinvolve an authentication party (with potential replications in master-slave relationships).Figure 3 shows an example of such an authentication process:SIST EN 301 261-3 V1.2.1:2003



ETSIEN 301 261-3 V1.2.1 (1999-01)12Authentication PartyClaimantcallingpartycalled party(3) Requestwith authentication informationVerifier(6) Response(2) Responsewith authenticationinformation(1) Request forgeneration of (some) authenticationinformation(4) Request for verifying the authentication
information (5) Verification responseFigure 3: Example of an authentication flow by using an authentication partyThe authentication information, which is necessary for an authentication process, will be generated by the authenticationparty (step 1 and 2). The authentication information will be transmitted via the existing application layer services of theOSI protocol stack (step 3). For verifying the authentication information, the called party may use the authenticationparty (step 4 and 5). Possibly responses (6) of the called party are: accept or reject.Currently, the authentication mechanisms described in [4] and [5] only specify the authentication information exchangesbetween the calling party and the called party. They do not describe (in contradiction to the framework part [3]), howthe authentication information will be generated and verified, especially, how an authentication party can be introduced.In general, an authentication party can be used at each site for the generation and / or for the verification of theauthentication information. Therefore, each authentication mechanism leads to the following four implementationvariants:calling partycalled partyvariant 1not using an authentication partynot using an authentication partyvariant 2using an authentication partynot using an authentication partyvariant 3not using an authentication partyusing an authentication partyvariant 4using an authentication partyusing an authentication partyThe calling party and the called party may interact with different authentication parties. The data flow and the protocolhandling between authentication party and calling respective called party is outside the scope of the present document.However, it is important to know, that this communication shall be handled in a secure manner.SIST EN 301 261-3 V1.2.1:2003



ETSIEN 301 261-3 V1.2.1 (1999-01)135Authentication servicesOne can distinguish between three types of authentication services:-the human user authentication;-the peer-to-peer entity authentication;-and the data origin authentication.5.1Human user authenticationHuman user authentication provides assurance of the identity of human operators.The operators are working at a TMN system (i.e. OS, NE, MF) via a Workstation. There exist two scenarios:-Scenario 1: The Workstation Function (WSF) is physically realized as part of the OS/NE/MF;-Scenario 2: The WSF is realized in a dedicated WS that is physically separated (connected via an F-interface)from the OS/NE/MF.In both scenarios, the human user will enter the authentication information to the workstation system (possibly by usinga user representation device like chipcard reader).With the first scenario, the authentication information submitted by the user can be directly verified by the TMN entitythat contains the WSF. With the second scenario, there is a question whether the WS is trusted by the OS/NE/MF or not.If the WS is a trusted entity, the authentication verification process may be completed by the WS. If the WS is nottrusted, however, the authentication information submitted by the human user must be securely transmitted across theF-interface for verification by the OS/NE/MF.If a human user is directly involved in the authentication process, then the human user authentication is by definition aunilateral function, i.e. the human user is authenticated towards the workstation system respective TMN system.Otherwise the human user is represented by a device, which is involved in the authentication process. In this case, thehuman user is authenticated into two steps: at first he is authenticated towards the user representation device in aunilateral way (e.g. by using a password mechanism) and secondly by applying a peer-to-peer authentication servicebetween the user representation device and the workstation system respective TMN system.5.2Peer-to-peer entity authenticationPeer-to-peer entity authentication provides assurance, during association setup, of the identities of remote TMN entities.Peer-to-peer entity authentication is a first step in establishing secure communications between systems (e.g. betweenoperations systems and network elements).Peer-to-peer entity authentication may provide either unilateral and mutual authentication. In the unilateral case, onlyone of the two communicating systems (the calling party) is authenticated towards the other (the called party), but in themutual case both communicating systems are authenticated towards each other.In the unilateral case, either one or two information transfers between calling party and called party are appropriate.In the mutual case, information will be transferred both from the calling to the called party and from the called to thecalling party.SIST EN 301 261-3 V1.2.1:2003



ETSIEN 301 261-3 V1.2.1 (1999-01)145.3Data origin authenticationData origin authentication provides assurance that a data item originates from an identified remote entity.For data origin authentication, the calling system appends to the data, e.g., a cryptographic checksum. Data originauthentication is only relevant in a unilateral way.In a connection-oriented environment like TMN, communicating entities authenticate each other at the time ofassociation establishment. In this case,
...