Subject: RE: [midcom] Comments on draft-stiemerling-midcom-semantics-02.txt: Session/Peer Identification

From: "Scott Cadzow" <[email-masked]>
Date: Tue, 24 Sep 2002 16:46:07 +0200

Whilst authentication as a goal is good it is the impact of that
authentication we need to worry about. What entity is authenticated and
against what knowledge? If every transaction is authenticated and a
middlebox randomly serves many users then authentication state
maintenance cannot be guaranteed. Key management (symmetric or
asymmetric) then becomes the dominant problem over and above the other
functions of the middlebox.
 
Tread warily.

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: 24 September 2002 16:11
To: [email-masked]
Cc: 'Juergen Quittek'; 'Martin Stiemerling'
Subject: [midcom] Comments on draft-stiemerling-midcom-semantics-02.txt:
Session/Peer Identification

This is a series of notes on the content of
draft-stiemerling-midcom-semantics-01.txt.  This note discusses the need
for content in each message which identifies the sender and possibly the
session with which the message is associated.

I'll deal with the session identifier first.  The first paragraph of
section 2.2 of the draft says that: 
 "Both agent and middlebox may participate in several sessions at the
same time." 

As I argue in draft-taylor-midcom-semgen-00.txt, this means at the very
least that every message must identify the sender, so that the receiver
can associate it with the right session.  Thus every request from the
agent must contain the agent identifier, and every response and
notification from the middlebox must contain the middlebox identifier,
as one of its parameters.

Does this identification have to go so far as to require an
authentication token in every message? 

Aside from this general question, I believe it would make sense for the
middlebox to authenticate itself in a Session Establishment reply in the
failure case as well as in the success case, to forestall a
man-in-the-middle DOS attack based on spurious rejection.

Tom Taylor 
[email-masked] 
Ph. +1 613 736 0961 (ESN 396 1490)