19.12.2012 Views

IT Baseline Protection Manual - The Information Warfare Site

IT Baseline Protection Manual - The Information Warfare Site

IT Baseline Protection Manual - The Information Warfare Site

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Safeguard Catalogue - Communications Remarks<br />

____________________________________________________________________ .........................................<br />

S 5.50 Authentication via PAP/CHAP<br />

Initiation responsibility: <strong>IT</strong> Security Management, Administrators<br />

Implementation responsibility: Administrators<br />

Many ISDN cards support communications via a Point-to-Point Protocol<br />

(RFC 1661) after an ISDN switched connection has been established. This<br />

Internet standard also offers authentication protocols such as the Password<br />

Authentication Protocol (PAP) and the Challenge Handshake Authentication<br />

Protocol (CHAP) (RFC 1994). If the ISDN card in use provides these<br />

functions, authentication should be performed with the Challenge-Handshake<br />

Authentication Protocol instead of the Password Authentication Protocol,<br />

because in the case of the latter, the password used for authentication is<br />

transmitted in plain-text form.<br />

As a rule, the passwords used by PAP and CHAP are stored in the <strong>IT</strong> systems,<br />

so that they do not have to be entered by the user each time authentication is<br />

required. To allow continued use of these processes following a re-installation,<br />

the required passwords should be noted down and kept in a safe place (refer to<br />

S 2.22 Depositing of passwords).<br />

Mode of operation:<br />

CHAP always distinguishes between two types of communication partner:<br />

authenticator and peer. <strong>The</strong> authenticator is the communication partner<br />

requesting authentication, while the peer is the communication partner<br />

needing to submit authentication. In general therefore, the authenticator<br />

comprises the server which users need to log into as peers from their<br />

respective <strong>IT</strong> systems.<br />

CHAP checks for the recognition of a common secret (password) on both<br />

communicating sides. This password is not transferred as plain text through<br />

the communications lines, and is protected against replay by integrating<br />

random numbers.<br />

A Challenge-Response-Protocol is sequenced as follows:<br />

To start with, the authenticator computes a random number. <strong>The</strong> hash value of<br />

the computed, random number is then formed using a hash algorithm. A hash<br />

function is a computing instruction which converts inputs of any length into<br />

outputs of a fixed (usually shorter) length. A one-way hash function only<br />

works in one direction, i.e. it easily allows hash values to be calculated from<br />

inputs, but makes it very difficult, if not impossible, to calculate inputs<br />

corresponding to hash values.<br />

In the next step, the authenticator transfers the challenge, i.e. the random<br />

number just calculated, to the peer. As the authenticator and peer both possess<br />

the same hash algorithm, the peer is able to form the hash value of the<br />

transferred random number in a fourth step. <strong>The</strong> peer calculates the hash value<br />

using three parameters: the identifier (user ID), secret (password) and the<br />

transferred random number. It then transmits the hash value as a response to<br />

the authenticator. <strong>The</strong> authenticator checks the correctness of the password by<br />

also calculating the corresponding hash value and comparing it with the<br />

received one. If the comparison is positive, the peer has been successfully<br />

____________________________________________________________________ .........................................<br />

<strong>IT</strong>-<strong>Baseline</strong> <strong>Protection</strong> <strong>Manual</strong>: Oktober 2000

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!