Low Assurance Protection Profile for an instant

messaging systems

Version

1.3

Date

6th April 2008

Author (s)

ali ayoub

Certification ID

BSI-PP-0015

Sponsor

TNO-ITSEF BV

File name
Profile

Instant messaging systems Low Assurance Protection

No of pages

Document information
Date of issue
Author(s)
Version number report
Certification ID
Scheme
Sponsor

6th April 2015

Ali ayoub
1.3
BSI-PP-0015
BSI
TNO-ITSEF BV

Sponsor address
Evaluation Lab
Evaluation Lab address

SRC

Project leader
Target of Evaluation (TOE)
TOE reference name
CC-EAL number
Classification
Report title
systems
Report reference name

al jadriya Baghdad- iraq

Graurheindorferstrasse 149a
D-53117 Bonn
Germany
Ali ayoub
instant messaging systems
instant messaging system
1
Final
Low Assurance Protection Profile for an instant messaging
PP- instant messaging systems -1.3

Document history
Version

Date

Comment

0.1
0.2
0.3
0.4
1.0

27-Jan-04
01-Feb-04
27-Feb-04
8-Apr-04
13-Apr-04

Initial version
Initial review comments included
Strengthened compliance with CCv2.4
Added results from 6/7 April meeting
Added BSI comments

1.1
1.2
1.3

14-Apr-04
26 Apr 04
6 Apr 05

Added more BSI comments, submitted to SRC

Processed comments from SRC, final version
Incorporated Raised Interpretations, added certification ID

1. PP Introduction
1.1 PP Reference
This 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 Architecture

.The following figure shows the basic TOE architecture
Basic TOE Architecture
The 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 Architecture

The 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) Architecture

You 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 as Basic Instant Messaging Architecture. To
provide this functionality, you need to include the components listed in Basic Instan
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.

.See Authentication in a Basic Architecture for 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 Messenger

BigAnt 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

Bopup Communication Server -2

Bopup 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

DBabble -3

DBabble has one of the smallest feature sets of the software on this list (one-onone 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

Winpopup LAN Messenger -4

Winpopup 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

Conformance claims .2
2.1 Conformance claim
This Protection
Profile:
Claims
conformance
to CC version
2.4 release
256 and
v2.4Draft
Interpretation1
#1-#17

 is CC Part 2 conformant and CC Part 3 conformant.

does not claim conformance to any other PP.
is EAL 1 conformant
Conformance claim rationale 2.2
PP-related conformance claim rationale
This PP does not claim conformance to another PP, so there is no rationale related
to this.
Package-related conformance claim rationale
This PP is EAL1 conformant. The EAL1 package contains no uncompleted
operations. As no SARs were added to EAL1, the SARs in this PP are consistent
.with EAL1

Conformance statement 2.3

Security targets or other PPs wishing to claim conformance to this PP can do so as
.strict-PP-conformance. Demonstrable-PP-conformance is not allowed for this PP
Definition of terms .3

3.1 Definition of subjects, information and operations

This section is added to define the terms that are used in the Security Objectives of
.the Operational Environment and SFRs

Subjects 3.2
A human that uses S.IN_SERVER

S.HOST

A human that administers the TOE

S.ADMIN

S.IN_SERVER or S.OUT_SERVER

S.SERVER

A instant messaging SERVER that is part of the TOE

A Web SERVER that is not part of the TOE

S.IN_SERVER
S.OUT_SERVER

Operations 3.3
:The operations that are performed by the TOE are
S.SERVER connecting to S.HOST

R.CONNECT

S.HOST retrieving voicemail from the TOE

R.GET_VMAIL

S.HOST deleting voicemail from the TOE

R.DEL_VMAIL

S.HOST asking for resource from TOE

S.HOST deleting resource from TOE

R.GET_RESOURCE
R.DEL_RESOURCE

Objects 3.4
TSF data: a relation representing the allowed

D.ALLOWLIST

connections between devices

Security Objectives for the Operational Environment .4

:The operational environment of the TOE shall conform to the following objectives
OE.SERVER_LOCATION

The operational environment of the Web server shall

be a general office-type environment: physical access is

.restricted to office personnel, visitors and the like

S.HOST shall be responsible for entry to the LDAP SERVER for

authentication and lookup process otherwise S.HOST shall
be blocked

OE.LDAP SERVER

The Operational Environment shall contain an IP network

:the IP-Network shall ensure that

OE.NETWORK

OE.NW_FEATURES

High security links between the S.HOST and S.SERVER

High availability (Redundancy ) links between S.HOST

and SERVER

Security Requirements .5
Extended components definition 5.1
As this PP does not contain extended security requirements, there are no extended

.components
5.2 SFRs
The SFRs are grouped for easy understanding:
Storing and retrieving voicemail
Managing servers
Identifying users
Logging and auditing

Self-protection

Storing and retrieving Voice mail 5.2.1

FIA_UAU.1 Timing of authentication
FIA_UAU.1.1 The TSF shall allow all actions except R.GET_VMAIL,
R.DEL_VMAIL, [assignment: other actions] on behalf of
S.HOST to be performed before S.HOST is authenticated.
FIA_UAU.1.2 The TSF shall require S.HOST to be successfully authenticated
before allowing any other TSF-mediated actions on behalf of
.S.HOST

Managing Servers 5.2.2

Informal 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 of
.Servers

that are part of the TOE

FMT_MSA.1 Management of security attributes

FMT_MSA.1.1
The TSF shall enforce the ConnectPolicy to restrict the ability to
modify the security attributes S.IN_SERVER/IP ADDRESS to
S.ADMIN.
FIA_UAU.2 User authentication before any action
FIA_UAU.12.12
The TSF shall require S.ADMIN to be successfully
authenticated before allowing any other actions related to the
other SFRs on behalf of S.ADMIN.

5.2.3 Identifying users

FMT_SMR.1 Security roles
FMT_SMR.1.1
The TSF shall maintain the roles
S.HOST
S.ADMIN
FMT_SMR.1.2
The TSF shall be able to associate users with roles
FIA_UID.2 User identification before any action
FIA_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 generation
FAU_GEN.1.1
The TSF shall be able to generate an audit record of the following
auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the not specified level of audit; and
c) 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 the
following information:
a) Date and time of the event, type of event, subject identity, and
the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event
definitions of the functional components included in the PP/ST

5.2.5 Self-protection
FPT_SEP.1 TSF domain separation

FPT_SEP.1.1

The TSF shall maintain a security domain for its own execution that
protects it from interference and tampering by untrusted subjects.
FPT_SEP.1.2 The TSF shall enforce separation between the security

domains of
subjects in the TSC.
5.3 SARs
The SARs for this PP are the package EAL 1 with one refinement in
AGD_USR.1.3:
AGD_USR.1.3C

The user guidance shall contain warnings about user-accessible

functions and privileges that should be controlled in a secure processing
environment. This shall include any and all means in which
S.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