Subject: [Rserpool] Minutes of the security design team -- May 6, 2003

From: [email-masked]
Date: Tue, 13 May 2003 14:31:10 -0500

Attending the teleconference on May 6, 2003 were:

Aron Silverton
Maureen Stillman
Michael Tuexen

1) Ports for ENRP and ASAP

We received a response to our question about the use of two ports for ENRP -- one for secure communications via TLS and the other for insecure.  Jon Peterson consulted with Eric Rescorla and they said two ports or one port -- both were acceptable.  Based on this response we are interested in the two port option for reasons of implementation simplicity.  Therefore, we need to make the request to IANA for the following:

We need port numbers for the ENRP server and for ASAP.
We need two port numbers each for SCTP, TCP: one secure, one not secure

At the same time, we will request a multicast port/address for ENRP.  Michael will propose what we need as this was not clear.

Action item:  Michael will draft an e-mail with what we need and send it to the Rserpool mailing list for review and comment.

2) Mixed response of secure and insecure items in the namespace for the client

ENRP servers that have both: PE registrations using TLS and PE registrations not using TLS
There were two options discussed:

Option 1) PE registration entries that had used TLS would be flagged as such.  The ENRP server would pass along a list to the PU with some entries marked as "secured" and others marked as not.
Option 2) An ENRP server that supports security would only accept PE input that used TLS.  All other registrations would be rejected.  Then, when the PU requests a pool name resolution (securely), it would get only secured entries in response. 

The reason to support #1 is that it lets the PU decide what entries to use, trusted or not.
The reason to support #2 is simplicity and support for a consistent security policy. 

The question concerns whether to allow for a "split" namespace in which some of the pool entries are "secured" and some are not.  

We did not receive a response from Eric Rescorla on this item.  Due to the response on the first item, we decided for reasons of simplicity to go with option 2. 

This simplifies both the implementation and the protocol.  No changes to the ASAP protocol are necessary.  If security is required, all communication would be done using TLS on the secured ports and the PU would receive only trusted entries.  If security is not required, then all communication would be done on the unsecured ports and the PU would receive untrusted entries.

Comments on this proposal or on the minutes?

-- maureen  

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool