Subject: Re: Agenda for SACRED in London

From: Dale Gustafson <[email-masked]>
Date: Mon, 06 Aug 2001 10:56:44 -0500

Hi All,

I will not be able to attend the London meeting due to other business
committments -- I believe Magnus will handle the planned Framework Draft
discussion (per our most recent email exchange).

Best Regards,

Dale Gustafson
PKI / Security Consultant
Future Foundation, Inc.
+1 651 452-9033 office
+1 218 343-9724 mobile

Magnus Nystrom wrote:

> Dear WG,
>
> Please find SACRED's London agenda below. A couple of small
> modifications have been made to the earlier proposal (added item 6,
> also discussed in Minneapolis, and switched order on item 4 and 5),
> based on comments received (off-list).
>
> SACRED meeting agenda, 51st IETF, London
> ----------------------------------------
>
> 1. Introduction, Agenda walkthrough     ( 5 min) WG Chairs
> 2. Working Group Status                 ( 5 min) WG Chairs
> 3. Requirement Draft update             ( 5 min) A. Arsenault
> 4. Protocol Draft discussion            (40 min) Authors
> 5. Framework Draft discussion           (30 min) D. Gustafsson
> 6. PKI Enrollment Information Storage   (10 min) N. Kapidzic Cicovic
> 7. AOB                                  (20 min)
> 8. Wrap up                              ( 5 min) WG Chairs
>
> Should anyone wish to present something under item 7, please get in
> touch with me or Stephen Farrell.
>
> Looking forward to see you all in London,
>
> -- Magnus
> Magnus Nystrom
> RSA Security

---

From: John W Noerenberg II <[email-masked]>
Date: Thu, 9 Aug 2001 11:34:31 +0100

I know it's late in the game, but, as a believer in distributed 
systems, I am compelled to comment on a tacit assumption in the 
framework draft.  It is assumed that servers necessarily are used for 
large communities of users.  Sacred protocols certainly fit that 
situation.  However, there is no reason to suppose they would be used 
only in that situation.  For example, a credential server could be 
used for a small community - a family, a department of co-workers, a 
community service organization - that has an interest in preserving 
their cohesion and the privacy of their communication.

Sec 2.1 contrasts the use of a credential server with direct transfer 
of credentials, asserting that direct transfer is always a safe 
operation.  The only time it is safe is when there are no intervening 
nodes through which the credentials pass.  The specific example given 
provides several opportunities for the credential to be edited in 
ways Alice doesn't expect or intend.

With this in mind, I propose the language in 2.1 be modified along 
these lines (addition in bold):

    However, the credential server approach has some potential
    disadvantages, too:

    1.  It might be somewhat expensive to maintain and run the 
credential server, particularly if there are stringent requirements 
on availability and reliability of the server. This is particularly 
true for servers which are used for a large community of users.  When 
the server server is intended for a small community, the complexity 
and cost would be much less.

The following paragraph is problematic.

    For example, consider the case where Mimi sends a message from her
    wireless phone containing the credentials in question, and retrieves
    it using her two-way pager.  In getting from one place to another,
    the bits of the message cross the wireless phone network to a base
    station. These bits are likely transferred over the wired phone
    network to a message server run by the wireless phone operator, and
    are transferred from there over the Internet to a message server run
    by the paging operator. From the paging operator they are
    transferred to a base station and then finally to Mimi's pager.
    Certainly, there are devices other than the original wireless phone
    and ultimate pager that are involved in the credential transfer, in
    the sense that they transmit bits from one place to another.
    However, to all devices except the pager and the wireless phone,
    what is being transferred is an un-interpreted and unprocessed set
    of bits.  No security-related decisions are made, and no actions are
    taken based on the fact that this message contains credentials, at
    any of the intermediate nodes.  They exist simply to forward bits.
    Thus, we consider this to be a "direct" transfer of credentials.

    Solutions involving the direct transfer of credentials from one
    device to another are potentially somewhat more complex than the
    credential-server approach, owing to the large number of different
    devices and formats that may have to be supported. Complexity is
    also added due to the fact that each device may in turn have to
    exhibit the behavior of both a client and a server.

Better might be:

For example, consider the case where Mimi sends a message from her 
wireless phone containing the credentials in question, and retrieves 
it using her two-way pager.  As long as Mimi's phone and pager can 
communicate directly, that is without the use of any network 
connections, credentials can be safely transferred.

Unless the direct transfer of credentials between devices follows a 
uniform methodology regardless of the type of devices, direct 
transfer would be complicated, or even prohibited because a 
consistent method and representation is not used.  This presumes at 
least some devices must be both a client and server for the exchange 
of credentials.

These ideas may have further implications for the requirements.  For 
the sake of brevity that potential should be pursued separately.
-- 

john noerenberg
[email-masked]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Aug 2001 12:40:26 +0100

Hi John,

John W Noerenberg II wrote:

> I know it's late in the game, but, as a believer in distributed systems, I am compelled 
> to comment on a tacit assumption in the framework draft.

I guess you mean the requirements draft, since that's where the text you're quoting
comes from.

> [...]Sacred protocols certainly fit that situation.  However, there is no
> reason to suppose they would be used only in that situation.  For example, a credential server
> could be used for a small community - a family, a department of co-workers, a community service
> organization - that has an interest in preserving their cohesion and the privacy of their
> communication.

I agree.
 
> With this in mind, I propose the language in 2.1 be modified along these lines (addition in bold):
> 
>         1.  It might be somewhat expensive to maintain and run the  credential server,
>      particularly if there are stringent requirements on availability and reliability of the
>      server. This is particularly true for servers which are used for a large community of
>      users.  When the server server is intended for a small community, the complexity and
>      cost would be much less.

That looks fine to me & I guess could be added without needing a new last call.

> Sec 2.1 contrasts the use of a credential server with direct transfer of 
> credentials, asserting that direct transfer is always a safe operation.

I don't think the text asserts "is always a safe operation".

> The only time it is safe is when there are no intervening nodes through 
> which the credentials pass. The specific example given provides several 
> opportunities for the credential to be edited in ways Alice doesn't expect
> or intend.

I don't think that's correct. Trivially, Alice can encrypt her credential
(Y) with a randomly generated strong symmetric key K; print K and send 
{Y}K over any untrusted route. To recover her credential, she types in K 
and decrypts {Y}K whenever it arrives. A direct connection (in network
terms) is not required, though this scheme does fit how "direct" is
defined/used in the requirements document.

The point is not that this is a good scheme, (it isn't), but that
its possible and since there are many cleverer people than me in the
world, I wouldn't rule out some good scheme being possible. 

For this reason, I'd argue that we don't need to make the second 
change you propose.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com