Based on Template

 

Created By

Kankan Roy

 

 

Software Functional Specification

Message authentication between communicating AVM Components

Reviewers

Department

Name/Title

Development Engineering

 

DevTest Engineering

 

Compliance

 

Customer Advocacy

 

The departments and/or individuals listed above should be notified in advance and given a sufficient time period to review this document. The Project Team determines requirements for approval according to the scope of the project.

 

 

Modification History

Revision

Date

Originator

Comments

1

 

 

 

 

 

 

 

 


Table of Contents

Application Visibility & Management Error! Bookmark not defined.

Version 2.1. Error! Bookmark not defined.

Software Functional Specification. 1

Reviewers. 1

Modification History. 1

1     Problem Definition. 4

1.1     Overview of AVM 2.1. 4

1.2     AVM Components. 4

1.3     Authentic Communication Functional Requirement 4

2     Software Architecture. 5

2.1     AVM’s underlying Framework and environment 5

2.2     NMP Studio, designer for AVM components. 5

3     Software Requirements. 5

3.1     Authentication of AVM communication. 5

3.2     SSH-2: 6

3.3     TLS/SSL: 6

3.4     HMAC: 6

3.5     Hybrid: 7

3.6     Selection of HMAC.. 7

3.6.1     Filters. 7

3.7     Alternatives for AVM.. 7

3.8     Implementation Strategy. 7

3.8.1     HMAC for structured messages XML and HTTP. 8

3.9     HMAC MD5 Java Example. 8

3.9.1     Java Cryptography References. 9

3.10      HMAC in the message. 9

3.10.1       Email Client: 9

3.10.1.1    AUTH CRAM-MD5 EXPLANATION.. 9

3.10.2       HTTP: 10

3.10.3       RMI Message. 10

3.10.4       Hub Port Messages: 10

3.10.4.1    Example. 10

3.10.4.2    New NMP Agent Property. 11

3.10.5       JMS Messages: 11

4     Memory and Performance Impact 11

5     Packaging Considerations. 11

6     End User Interface. 11

7     Configuration and Restrictions. 11

8     Testing Considerations. 11

9     Patentability Considerations. 12

10      Architecture Baseline Requirements. 12

11      Accessibility Requirements. 12

12      Product Evolution Program, PEP. 12

13      Requirements Traceability Considerations. 12

14      References. 12

15      Glossary. 12

16      Attachments. 13

 

 

 


 

1       Problem Definition

1.1    Overview of AVM 2.1

 

Application Visibility & Management (AVM) provides the application level behavior analysis and profiling in the context of business processes. AVM is software agnostic. AVM oversees inter network traffic and analyzes traffic behavior, identifies Transactions, Applications and Processes; constructs topology of application components; measures and reports performance.

AVM has multi tier architecture – separate components may be factored into different server (Hardware) Container. Network traffic is collected at Switches in Promiscuous mode and directed to Traffic Collector.

1.2    AVM Components

 

AVM Server and CCP (connection & control point) are two parts. AVM server is responsible for presentation, administration and management of Information collected by CCP. CCP is responsible for Traffic Collection, Node Collection, Node Analysis and Traffic Analysis.

1.3    Authentic Communication Functional Requirement

 

This document reviews secured communication technology with a view to implement some of them for messaging between AVM Components. It endeavors to specify what is required to ensure the communications between AVM Components in the network are uncorrupted and AUTHENTIC AVM messages. AVM messages are desirably PRIVATE (i.e. not easily decipherable). This document also analyzes several alternatives schemes.

 

 

2       Software Architecture

2.1    AVM’s underlying Framework and environment

 

NMP 4.0 is an integrated, Java-based, web-services platform used to create dynamic,

Real-time, business information displays. NMP 4.0 is designed to support capture and display of Enterprise Risk Management information in a networking environment. All AVM components are designed and built using NMP Studio and they are supported with NMP framework and executes as NMP application in NMP Run Time Environment. NMP runtime environment consists of Web Application Server, Database Information Server and managed Network, Entity and Presentation service functionality. Web Application and Database servers are user selectable and configurable. The present NMP runtime environment for AVM consists of Tomcat Application Server, Stand alone Spring container and MySQL Database Server. AVM components are connected with each other using JMS Broker and RMI.

 

2.2    NMP Studio, designer for AVM components

 

All AVM components are designed and built using NMP studio and functions within NMP’s runtime environment. NMP Entities in an AVM component are used for Information model, data collection, data analysis, data store and presentation. NMP Entities may receive and send messages through defined Node Points called Business Information Network (or simply BIN) to other AVM components, or to outside world.

 

BINs have three components – Hubs (public channels that pass information packets from one source to many), Ports (receive or send information packets, and LINKED with Agents), Agents (programmable, created directly in the BIN, unaware of other Agents or their usages). LINKS establishes connections between all objects in a BIN, Agents, Hubs and Ports. LINKS are created at Design Time with NMP Studio.

 

NMP Agents are of the following types:

·       Echo

·       Email

·       Web Service

·       Java

·       XPath Filter

·       XSL Transform

·       Entity

·       Virtual Metrics

·       Http/CGI

 

3       Software Requirements

3.1    Authentication of AVM communication

 

Messages exchanged within AVM using Agents or otherwise need be authenticated. Service Requirement proposal for next release of AVM identifies three possible mechanisms for message exchange - SSL, SSH and HMAC. Further, the authentication need be done in the NMP layer if not in Spring container layer or Web Server Layer.

 

3.2    SSH-2:

·       The transport layer (RFC 4253). This layer handles initial key exchange and server authentication and sets up encryption, compression and integrity verification.

·       The user authentication layer (RFC 4252).

·       The connection layer (RFC 4254).

3.3    TLS/SSL:

TLS/SSL has a variety of security measures:

3.4    HMAC:

·       An iterative hash function breaks up a message into blocks of a fixed size and iterates over them with a compression function. For example, MD5 and SHA-1 operate on 512-bit blocks. The size of the output of HMAC is the same as that of the underlying hash function (128 or 160 bits respectively for MD5 or SHA-1, respectively). [RFC for HMAC http://www.faqs.org/rfcs/rfc2104.html ]

·       The following pseudo code demonstrates how HMAC may be implemented.

function hmac (key, message)
    opad = [0x5c * blocksize] // Where blocksize is that of the underlying hash function
    ipad = [0x36 * blocksize]
 
    if (length(key) > blocksize) then
        key = hash(key) // keys longer than blocksize are shortened
    end if
 
    for i from 0 to length(key) - 1 step 1
        ipad[i] = ipad[i] XOR key[i]
        opad[i] = opad[i] XOR key[i]
    end for
 
    return hash(opad || hash(ipad || message)) // Where || is concatenation
end function

·       Messages to be authenticated arrive with three identifiable components SOURCE, HMAC, and Message body. Only authenticated Messages are processed. Similarly messages to be sent is appended with Source and HMAC and sent into wire along with the message.

3.5    Hybrid:

·       Symmetric Key Encryption along with HMAC (Key may be the same or similar for both).

3.6    Selection of HMAC

 

Without going into relative merit of the Authentication advantage of one over the other, it is felt that Messages need only be verified for no modification and no loss. Further there need be some degree of confidence that the message is sent from another (known) AVM component.

Thus we shall be proposing to implement HMAC only for message exchange between AVM components. (Hash function say is MD5).

3.6.1  Filters

 

Filters ideally should be easily pluggable at NMP/AVM web or Spring container for creation and verification of Authentic message.

At Sender, messages to be sent are pre-processed with Filter, which appropriately creates new message of the same message type with Source and HMAC along with message.

At Receiver, it should be possible to intercept messages received and authenticate the same with some Filters depending on Message type. The output from the filter is the message received by the Filter at Sender; if the message fails to pass authentication the filter should exit processing of message giving some Error Message like HTTP/RMI error message if required.

 

3.7    Alternatives for AVM

 

Here we shall consider some alternatives:

 

KEY:

·       HMAC key is ONE and KNOWN to all AVM Components and is not known to outside world

·       HMAC Keys are different for different AVM components. They are known among AVM Components but are not known to outside world.

 

IMPLEMENTATION OF AUTHENTICATION:

·       Send / Receive HMAC Authentications are done within AVM Agents

·       Authentication is done at NMP Layer needing no changes in the AVM Components by FILTERS.

 

3.8    Implementation of HMAC

 

HMAC is a Java Class that populates its key store from Hmac Keys that will be used by all AVM Components. createHmac and athenticateHmac are two methods to create and verify Message Authenticity. Interceptor/Filters for all messages inbound and outbound shall use these methods. Interceptors are different for different message types and are intended for NMP BIN Agent – Email, Web Service, XML, HTTP, Plaintext etc.

 

Key Generation:

 

 

 

3.8.1  HMAC for structured messages XML and HTTP

HMAC is computed for the Message content only and not for tags or delimiters occurring between tags. This is also proposed in Exclusive xml Canonicalization Vs 1, July 2002.   http://www.w3.org/TR/2001/REC-xml-c14n-20010315

3.9    HMAC MD5 Java Example

·             /*
·              * Copyright 1997-2001 by Sun Microsystems, Inc.,
·              * 901 San Antonio Road, Palo Alto, California, 94303, U.S.A.
·              * All rights reserved.
·              *
·              * This software is the confidential and proprietary information
·              * of Sun Microsystems, Inc. ("Confidential Information").  You
·              * shall not disclose such Confidential Information and shall use
·              * it only in accordance with the terms of the license agreement
·              * you entered into with Sun.
·              */
·              
·             import java.security.*;
·             import javax.crypto.*;
·              
·             /**
·              * This program demonstrates how to generate a secret-key object for
·              * HMAC-MD5, and initialize an HMAC-MD5 object with it.
·              */
·              
·             public class initMac {
·              
·                 public static void main(String[] args) throws Exception {
·              
·                     // Generate secret key for HMAC-MD5
·                     KeyGenerator kg = KeyGenerator.getInstance("HmacMD5");
·                     SecretKey sk = kg.generateKey();
·              
·                     // Get instance of Mac object implementing HMAC-MD5, and 
·                     // initialize it with the above secret key
·                     Mac mac = Mac.getInstance("HmacMD5");
·                     mac.init(sk);
·                     byte[] result = mac.doFinal("Hi There".getBytes());
·                 }
·             }

3.9.1  Java Cryptography References

http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/JCERefGuide.html

http://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html

 

3.10       HMAC in the message

3.10.1 Email Client:

In CRAM-MD5 authentication the server first sends a challenge string to the client. The client responds with a username followed by a space character and then a 16-byte digest in hexadecimal notation. The digest is the output of HMAC-MD5 with the user's password as the secret key, and the server's original challenge as the message. The server also calculates its own digest with its notion of the user's password, and if the client's digest and the server's digest match then authentication was successful.

This provides three important types of security. First, others cannot duplicate the hash without knowing the password. This provides authentication. Second, others cannot replay the hash—it is dependent on the unpredictable challenge. This is variously called freshness or replay prevention. Third, observers do not learn the password. This is called secrecy. The two important features of this protocol that provide these three security benefits are the one-way hash and the fresh random challenge.

http://en.wikipedia.org/wiki/CRAM-MD5

SMTP Server responds with Authentication mechanism when queried with EHLO command.

 

3.10.1.1              AUTH CRAM-MD5 EXPLANATION


http://www.activexperts.com/support/activemail/auth/


While for AUTH PLAIN and LOGIN clear user names and password are transmitted, things go significantly more secure with the CRAM-MD5 authentication mechanism. As already mentioned in it's name, CRAM-MD5 combines a Challenge/Response mechanism to exchange information and a (cryptographic) Message Digest 5 algorithm to encrypt important information. I use an example based on a posting of Markus Stumpf (SpaceNet) to the Qmail mailing list. A typical ESMTP AUTH CRAM-MD5 dialog starts like this:

S: 220 popmail.space.net ESMTP

C: ehlo client.example.com

S: 250-popmail.space.net

S: 250-PIPELINING

S: 250-8BITMIME

S: 250-SIZE 0

S: 250 AUTH CRAM-MD5

C: auth cram-md5

S: 334 PDI0NjA5LjEwNDc5MTQwNDZAcG9wbWFpbC5TcGFjZS5OZXQ+

 

Unlike AUTH LOGIN, the server's response is now a one-time BASE64 encoded 'challenge'. The challenge 'PDI0NjA5LjEwNDc5MTQwNDZAcG9wbWFpbC5TcGFjZS5OZXQ+' translates to '<24609.1047914046@popmail.Space.Net>'. The leading and trailing brackets ('<', '>') are mandatory, as well the portion of the challenge which provides the hostname after the '@'. '24609.1047914046' is a random string, typically build from the 'pid' and the current time stamp to make that challenge unique.

While the user name is transmitted in clear text (but of course BASE64 encoded), the servers's challenge is used by the client to generate a 'digest' from the challenge and the password (which is commonly called 'secret' or 'shared secret' in this context) employing the following MD5 hashing algorithm:

digest = MD5(('secret' XOR opad), MD5(('secret' XOR ipad), challenge))

If both the ESMTP server and the client 'share' the same challenge and secret, the user may now be authenticated successfully by means of the transmitted and BASE 64 encoded 'user name' and 'digest'.

 

Here is an example for SMTP implementation of CRAM MD5 Authentication:

http://user.informatik.uni-goettingen.de/~teleprak/SS2007/emailproject-report.pdf

 

3.10.2 HTTP/1.1:

HTTP ‘extended entity headers’ are used to append authentication codes for outbound messages. Following are the lines added after the ‘start-line’:

$$ServerHash:24 characters Base64 server Index Hash

$$Hmac:24 characters Base64 Message Hash

These headers are stripped off from the message after authentication.

Followings are two Filtering methods:

messageFilterOutboundHTTP(String message)

messageFilterInboundHTTP(String message)

 

 

http://ftp.ics.uci.edu/pub/ietf/http/rfc2616.pdf
 
 

3.10.3 RMI Message

RMI Authentication is more involved than other message types. It shall be required to create a new RMI Authentication Interface both for Server and Client. Their implementation shall accomplish messages authentication of messages exchanged. In this version it is not implemented.

3.10.4 Hub Port Messages:

Outbound XML or Plaintext BIN Messages sent through hub port shall have three empty Tags shall be appended.

<24 characters Base64 server Hash/><24 characters Message Hash/><bin-type/>

Or

<24 characters Base64 server Hash/><24 characters Message Hash/><xml-type/>

Further XML messages are stripped of all formatting characters.

After authentication of inbound message, the appended texts are stripped off.

 

Simple XML messages can have <HMAC>base64 HMAC Digest</HMAC> and <SourceDigest> base64</SourceDigest> appended at the end of the message.

 

Non-XML message simply has Base64 Source and MD5 added each following with a colon (:) at the end of the message and ended with ‘= =’.

3.10.4.1              Example

<?xml version="1.0" encoding="ISO-8859-1"?>
<shiporder orderid="889923"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="shiporder.xsd">
 <orderperson>John Smith</orderperson>
 <shipto>
  <name>Ola Nordmann</name>
  <address>Langgt 23</address>
  <city>4000 Stavanger</city>
  <country>Norway</country>
 </shipto>
 <item>
  <title>Empire Burlesque</title>
  <note>Special Edition</note>
  <quantity>1</quantity>
  <price>10.90</price>
 </item>
 <item>
  <title>Hide your heart</title>
  <quantity>1</quantity>
  <price>9.90</price>
 </item>
</shiporder>

<SourceDigest>Base64SourceDigest</Source-Digest>

<HMAC-MD5>Base64MD5Hash</HMAC-MD5>

3.10.4.2              New NMP Agent Property

It is desirable that HMAC facility is implemented at NMP and is transparent to AVM developer. Only at design time an AVM Agent is declared with its HMAC property as TRUE and a Source property is associated with one of the possible enumerated (declared) AVM Source.

 

3.10.5 JMS Messages:

JMS messages may have a new property called HMAC wherein ‘HMAC’ and ‘Source’ may be sent in Base64. HMAC is calculated for Message Payload only as proposed in ‘Exclusive xml Canonicalization Vs 1, July 2002’.

4       Memory and Performance Impact

HMAC MD5 calculation for a message designed to be very fast and shall not make any impact on performance. However it is desirable that the message perhaps be encrypted with same Source Key used for HMAC and not sent in Plaintext.

 

5       Packaging Considerations

In case, HMAC MD5 enhancement is done at NMP BIN Message handling layer, it shall be part of NMP Framework. In case, it is implemented at AVM Agent code level, it would be part of the AVM Component and shipped with NMP. No additional consideration is required.

6       End User Interface

 

 

This functionality does not have any impact on end user interface.

7       Configuration and Restrictions

8       Testing Considerations

NMP has the facility to create BIN Agent called Echo. It may be used for testing other Agents implementation of Authentication.

9       Patentability Considerations

10 Architecture Baseline Requirements

11 Accessibility Requirements

 

The list of ADRs that this Software Functional Specification addresses is the following:

12 Product Evolution Program, PEP

13 Requirements Traceability Considerations

14 References

·    NMP 4.0 User Manual

·    Application Visibility and Management User Guide

·    AVM Software Functional Specification 2.1

15 Glossary

The following list describes acronyms and definitions for terms used throughout this document:

Device

        Device term is used for any hardware – Server, Router, Firewall, Switch, etc. Primarily Device is categorized as ‘Server’ device and ‘Network’ device.

Link

         Link is physical or logical in the context of infrastructure. Physical link is Layer 1 link – physical wire. Logical link is Layer 3 link, which is connectivity link.

         In the context of flow topology (communication), link is defined as relationship from client to server.

Application

          Application is a logical unit to capture a functional software. It can map to one or more application images (defined later) or System Processes (defined later).

Application Image

         Application Image is a software binary (and set of dependent binaries) which can take a shape of an application in a server environment or can be made available as an application through some container, like Application Server. Examples are exe files, main jars and wars files.

          Application Image can be of type executable (e.g exe) which can run on its own as software program or application component (e.g. jar) which needs host application like java or application server.

Package

         Applications and its components are bundled in logical units – Package, by vendors (Design time). In the infrastructure environment, this is the unit of install and uninstall. Package can be hierarchal and leaves are application images. In addition to application images, packages contain other components necessary for applications to run in the server environment, like configuration files, maintenance scripts/tools, libraries, etc.

System Process

         System Process is an instance of a computer program, which maps to a single application image. Server captures this by associating a unique process id.

          Process can be hierarchal. One process can spawn many processes of its own kind or different kinds.

Interface

          Interface is a port of communication on requester or responder side. Normally it is captured through IP address (System Unique Address), Port (Unique number in a server) and Protocol (communication protocol, like HTTP, TCP, etc.) One interface can belong to only one process at any given time.

Message

         A message in its most general meaning is an object of communication between two applications.

Request

          A message sent on the tcp connection from originator side (Client - Source) to other side of the connection (Server - Destination) is defined as request.

Response

            A message (or set of messages) coming back from server to client on the same connection is defined as response.

Connection Link (Link in Error! Reference source not found.)

             Tcp connection between client and server for the purpose of message flow is defined as connection link.

 

16 Attachments

Example Files relevant to NMP Framework deployment is included here. It is perceived that Acegi Security may be ideally suited for Spring Framework. http://www.acegisecurity.org/

Some of the Bootstrap files do refer to Acegi. But it may not be operative. Whether it is desirable is another question. Strong channel of communications between all the AVM components may be pre-established at start up eliminating need for individual method authentication.

HMAC Authentication scheme outlined in this document shall have to be integrated in the Framework of NMP and AVM.

 


 

16.1       Review Action Items

End of Document