Low Assurance Protection Profile for an instant messaging systems

Version1.3Date 6th April 2008Author (s)ali ayoubCertification ID BSI-PP-0015Sponsor TNO-ITSEF BVFile name Instant messaging systems Low Assurance Protection ProfileNo of pages 8Document informationDate of issue 6th April 2015Author(s) Ali ayoubVersion number report 1.3Certification ID BSI-PP-0015Scheme BSISponsorTNO-ITSEF BV

Sponsor address al jadriya Baghdad- iraq Evaluation Lab SRCEvaluation Lab address Graurheindorferstrasse 149aD-53117 BonnGermanyProject leader Ali ayoubTarget of Evaluation (TOE) instant messaging systemsTOE reference name instant messaging systemCC-EAL number 1Classification FinalReport title Low Assurance Protection Profile for an instant messaging systemsReport reference namePP- instant messaging systems -1.3Document historyVersion Date Comment0.1 27-Jan-04 Initial version0.2 01-Feb-04 Initial review comments included0.3 27-Feb-04 Strengthened compliance with CCv2.40.4 8-Apr-04 Added results from 6/7 April meeting1.0 13-Apr-04 Added BSI comments1.1 14-Apr-04 Added more BSI comments, submitted to SRC1.2 26 Apr 04 Processed comments from SRC, final version1.3 6 Apr 05 Incorporated Raised Interpretations, added certification ID

1. PP Introduction1.1 PP ReferenceThis is the Low Assurance Protection Profile for an instant messaging systems 1.3, TNO-ITSEF BV, 6th April 2015

1.2 TOE overview

Instant messaging is one of the earliest created network-based collaboration tools and still stands as the basis for all of the others. Pretty much every collaboration tool available on the market offers an instant messaging feature in addition to the voice, video, or screen sharing features they are most known for. However, for most instant messaging and collaboration tools, the service is hosted over the public Internet, resulting in the potential loss or theft of sensitive data or information, especially the data protected by laws such as Sarbanes-Oxley and HIPAA. Because of this risk, companies have looked for systems they can host within their own private network that will still offer the communications they need to conduct their business.Basic TOE ArchitectureThe following figure shows the basic TOE architecture.Basic TOE ArchitectureThe basic TOE architecture provides such functionality as presence, roster management, chat, news alerts, and conferences. To provide this basic functionality, you need to install the following components: Instant Messaging server and one or more Instant Messaging multiplexors Instant Messaging resources Web server such as Web Server LDAP server such as Directory Server

In this example: The LDAP server provides user entries for authentication and lookup. The clients download the Instant Messaging resources from either a web server or Application Server Clients always connect to the Instant Messaging server through an Instant Messaging multiplexor.

Authentication in a Basic TOE ArchitectureThe following figure shows the interaction of the software components in the authentication process of a basic architecture of Instant Messaging. The focus is on the flow of authentication requests. An explanation of the steps in this process follows the figure.Flow of Authentication Requests in a Basic Instant Messaging Architecture

The authentication process in a basic architecture works as follows:1. End user accesses the Instant Messenger applet URL from a browser and chooses a method to invoke the client.2. The browser invokes Java Web Start or the Java plugin.3. Java Web Start or the Java plugin downloads the necessary Instant Messenger resource files and starts Instant Messenger.4. The login window appears and the end user enters the login name and password. The login data is sent to the Instant Messaging server through the multiplexor.5. The Instant Messaging server communicates with the LDAP server to authenticate the end user and to request end-user information, such as contact lists or subscriptions.When the end-user authentication is complete, the Instant Messaging main window appears, displaying the contact list for the end user. The end user can now start and participate in Instant Messaging sessions with the other end users.

TOE Email Notification (Calendar Alert) ArchitectureYou can deploy Instant Messaging to support email notification to offline users, as well as Instant Messaging based notification of calendar events to users.An Instant Messaging architecture that supports email notification and calendar alerts provides the same functionality asBasic Instant Messaging Architecture. To provide this functionality, you need to include the components listed inBasic Instant Messaging Architecture. To support email alerts, you also install an SMTP server such as Messaging Server. To support calendar alerts, you also install Calendar Server.To enable email notification, you are prompted during installation to identify the SMTP server to use with Instant Messaging. If you do not have an SMTP server installed, you must install one before installing the Instant Messaging software. The following figure shows Instant Messaging with email notification enabled on the network.Instant Messaging Architecture with Email Notification

Authentication flow in this architecture is the same as in a basic deployment. SeeAuthentication in a Basic Architecturefor more information.

In this example: The LDAP server provides user entries for authentication and lookup. The Instant Messaging server forwards messages intended for offline users to the SMTP server. The SMTP server then sends the message as an email to the user's mailbox. The clients download the Instant Messaging resources from a web server (or application server). Clients always connect to the Instant Messaging server through an Instant Messaging multiplexor.The following figure shows Instant Messaging with calendar notification enabled on the network. If you do not have Calendar Server installed, you must install it before installing the Instant Messaging software.

Here is some TOE systems that are designed to be used within a private corporate network. These systems are generally client-server based (with one exception), have various feature sets, and are priced by client, by server, both, or - in one case - free.

1-BigAnt Instant MessengerBigAnt is a basic instant messaging system with a few additional niceties. In addition to the basic chat feature, it also offers offline messaging, group chat, and voice and video chat. Accounts can be set up manually or imported from Active Directory for easy setup. In case of audit by a regulatory body, BigAnt can log messages which the administrator can search, view, and print. The BigAnt client is able to be rebranded to show your company's logo and name. BigAnt Standard costs $299 for the server and $15.90 for each client license, which reduces with quantity. Additional features, including desktop sharing, bulletin boards, and document management are available with the Pro version

2-Bopup Communication ServerBopup has many of the same features as BigAnt, but it stops short at voice and video. It is capable of bulletin communications, Active Directory imports, file transfer and distribution, and they advertise that the client software works well with Citrix and Terminal Server environments. Again, message archiving is available for regulatory purposes. Bopup costs $190 for the server and $12.90 for each concurrent connection, with the client pricing reducing at certain quantities. Bopup also has a special offer for small businesses purchasing 10-20 client licenses: the server software is free.3-DBabbleDBabble has one of the smallest feature sets of the software on this list (one-on-one and group chat) but it is also highly customizable and configurable. System administrators are able to change nearly every piece of text on either the web or Windows client and insert images in designated spots, such as logos and even advertisement. DBabble has the capability of creating groups for IT support where the user is randomly assigned to an available support person for one-on-one chat. DBabble servers are capable of being configured in a master-slave architecture, but with an alleged capability of 10 million user databases and 10,000+ concurrent users per server, it's probably not something most admins will use. The DBabble server is available for Windows, Mac, and many versions of Linux and UNIX, and the web client only requires a browser with JavaScript 1.1. Pricing is per-server at $485.

4-Winpopup LAN MessengerWinpopup LAN messenger is the only selection on this list where the server software is optional; the client is capable of either client-server or peer-to-peer communications. However, given the fact that the server software is free, there's no reason to limit yourself to peer-to-peer communications unless you simply do not have a machine to put it on. Because of this simplicity, Winpopup LAN Messenger simply does not have a deep feature set either. It is limited to group and one-on-one chat. Winpopup LAN Messenger is free for up to three users and then costs $14.95 per license - again, like the others, with diminishing cost breakpoints.

2. Conformance claims2.1 Conformance claim

This Protection Profile: Claims conformance to CC version 2.4 release 256 and v2.4DraftInterpretation1 #1-#17 is CC Part 2 conformant and CC Part 3 conformant. does not claim conformance to any other PP. is EAL 1 conformant2.2 Conformance claim rationalePP-related conformance claim rationaleThis PP does not claim conformance to another PP, so there is no rationale relatedto this.Package-related conformance claim rationaleThis PP is EAL1 conformant. The EAL1 package contains no uncompletedoperations. As no SARs were added to EAL1, the SARs in this PP are consistentwith EAL1.2.3 Conformance statementSecurity targets or other PPs wishing to claim conformance to this PP can do so asstrict-PP-conformance. Demonstrable-PP-conformance is not allowed for this PP.3. Definition of terms3.1 Definition of subjects, information and operationsThis section is added to define the terms that are used in the Security Objectives ofthe Operational Environment and SFRs.

3.2 SubjectsS.HOSTA human that uses S.IN_SERVERS.ADMINA human that administers the TOES.SERVERS.IN_SERVER or S.OUT_SERVERS.IN_SERVERA instant messaging SERVER that is part of the TOES.OUT_SERVERA Web SERVER that is not part of the TOE3.3 OperationsThe operations that are performed by the TOE are:R.CONNECTS.SERVER connecting to S.HOSTR.GET_VMAILS.HOST retrieving voicemail from the TOER.DEL_VMAIL S.HOST deleting voicemail from the TOER.GET_RESOURCES.HOST asking for resource from TOER.DEL_RESOURCES.HOST deleting resource from TOE3.4 ObjectsD.ALLOWLIST TSF data: a relation representing the allowedconnections between devices

4. Security Objectives for the Operational EnvironmentThe operational environment of the TOE shall conform to the following objectives:OE.SERVER_LOCATION The operational environment of the Web server shallbe a general office-type environment: physical access isrestricted to office personnel, visitors and the like.

OE.LDAP SERVERS.HOST shall be responsible for entry to the LDAP SERVER for authentication and lookup process otherwise S.HOST shall be blockedOE.NETWORKThe Operational Environment shall contain an IP networkOE.NW_FEATURESthe IP-Network shall ensure that: High security links between the S.HOST and S.SERVER High availability (Redundancy ) links between S.HOST and SERVER

5. Security Requirements5.1 Extended components definitionAs this PP does not contain extended security requirements, there are no extendedcomponents.5.2 SFRs

The SFRs are grouped for easy understanding: Storing and retrieving voicemail Managing servers Identifying users Logging and auditing Self-protection5.2.1 Storing and retrieving Voice mailFIA_UAU.1 Timing of authenticationFIA_UAU.1.1 The TSF shall allow all actions except R.GET_VMAIL,R.DEL_VMAIL, [assignment: other actions] on behalf ofS.HOST to be performed before S.HOST is authenticated.FIA_UAU.1.2 The TSF shall require S.HOST to be successfully authenticatedbefore allowing any other TSF-mediated actions on behalf ofS.HOST.5.2.2 Managing ServersInformal Explanation (informative) Only the administrator can change the Ip address of a Web server The SFR is limited to S.IN_SERVER: the TOE can change only the Ip addresses ofServers that are part of the TOE.FMT_MSA.1 Management of security attributesFMT_MSA.1.1 The TSF shall enforce the ConnectPolicy to restrict the ability tomodify the security attributes S.IN_SERVER/IP ADDRESS to S.ADMIN.

FIA_UAU.2 User authentication before any actionFIA_UAU.12.12 The TSF shall require S.ADMIN to be successfullyauthenticated before allowing any other actions related to theother SFRs on behalf of S.ADMIN.

5.2.3 Identifying users

FMT_SMR.1 Security rolesFMT_SMR.1.1 The TSF shall maintain the roles S.HOST S.ADMINFMT_SMR.1.2 The TSF shall be able to associate users with rolesFIA_UID.2 User identification before any actionFIA_UID.2.1 The TSF shall require each user to identify itself before allowing any other TSF-mediated actions on behalf of that user.

5.2.4 Logging and auditing

FAU_GEN.1 Audit data generationFAU_GEN.1.1 The TSF shall be able to generate an audit record of the followingauditable events:a) Start-up and shutdown of the audit functions;b) All auditable events for the not specified level of audit; andc) Registration of a new S.IN_PHONE,modification of the configuration of S.IN_PHONE,failed authentication events,FAU_GEN.1.2 The TSF shall record within each audit record at least thefollowing information:a) Date and time of the event, type of event, subject identity, andthe outcome (success or failure) of the event; andb) For each audit event type, based on the auditable eventdefinitions of the functional components included in the PP/ST

5.2.5 Self-protection

FPT_SEP.1 TSF domain separationFPT_SEP.1.1 The TSF shall maintain a security domain for its own execution thatprotects it from interference and tampering by untrusted subjects.FPT_SEP.1.2 The TSF shall enforce separation between the security domains ofsubjects in the TSC.

5.3 SARsThe SARs for this PP are the package EAL 1 with one refinement inAGD_USR.1.3:

AGD_USR.1.3C The user guidance shall contain warnings about user-accessiblefunctions and privileges that should be controlled in a secure processingenvironment. This shall include any and all means in whichS.IN_SERVER can be used to eavesdrop on S.HOST by e.g.:

Using a Tunnel to Capture the HTTP Message Exchange Using a Network Sniffer to Capture the HTTP Message Exchange