Subject: [Rserpool] Minutes from last security design team conference call -- next teleconference Tuesday May 6

From: [email-masked]
Date: Mon, 28 Apr 2003 09:39:29 -0500

The next conference call will be held on Tuesday, May 6 at 10AM EDT USA.

Minutes of the security design team conference call on April 15

Attending the conference call:

Randy Stewart
Maureen Stillman
Aron Silverton
Michael Tuexen
Qiaobing Xie

1) I sent an e-mail to our area directors regarding the issue of one port versus two for secure versus insecure communication.  Jon Peterson answered below.

2) We continued our discussion of the security of individual entries in the ENRP namespace.  This issue was raised on the mailing list after our last teleconference.  We decided to get the opinion of Eric Rescorla.  The e-mail message to him is attached below.  I will post the response when I receive it.

3) Next teleconference is Tuesday, May 6 at 10AM EDT USA.

-- maureen

Attachment #1

-----Original Message-----
From: ext Peterson, Jon [mailto:[email-masked]]
Sent: Friday, April 25, 2003 5:42 PM
To: Stillman Maureen (NVO-NIC/Ithaca); [email-masked]
Cc: [email-masked]
Subject: RE: Question on ports for ENRP name server

If there is any real policy, it's specified in RFC2817, which recommends a
single-port approach. Some problems with a two-port approach are also
described in RFC2595 (section 7). I have, however, detected widespread
skepticism about one-port protocols that use upward negotiation (like HTTP
UPGRADE) from insecure to secure connections; while the spirit of RFC2817 is
good, the mechanism itself is largely broken.

So, as far as I know there's no consensus that either the one port or two
port approach is superior. Our Transport Area security advisor tells us that
either way is okay (or at least either way is equally fraught with
pitfalls).

- J

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 25, 2003 10:38 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Question on ports for ENRP name server
> 
> 
> The Reserpool security design team has been meeting and 
> recently we have a question about ports.
> 
> We are strongly in favor of using TLS for security in 
> Reserpool to protect the integrity of the namespace.  TLS 
> would be mandatory to implement but optional to use.   The 
> question concerns using one port or two ports for insecure 
> vs. secure communication with the ENRP server for 
> registration by a Pool element.  One port for insecure 
> registrations from pool elements offering a services and the 
> second port for secure registrations using TLS.  The group 
> would like to have 2 ports as this would make implementation 
> easier.  Is there any problem with this?  What is the current 
> policy on 2 ports versus one port?
> 
> Thanks.
> 
> -- maureen
> 

Attachment #2
to Eric Rescorla:

We have another question about Rserpool security.

ENRP server = name server
PE = pool element (server where the service resides)
PU = pool user
PEs register with the ENRP server using a pool handle (name) to indicate that they support a service or a set of services

The security design team reached consensus on using TLS from the PE to the ENRP server and between ENRP servers to guarantee the following properties:
1) the integrity of the nameserver information sent from the ENRP server to the client
2) the integrity of the registration information sent from the PE to the ENRP server
3) ensuring that a PE registers with a legitimate (non-rogue) ENRP server

The open issue that this raised is:

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

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.
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 list, it would have only secured entries. 

The reason to support #1 is that it lets the PU decide what entries to trust.
The reason to support #2 is simplicity and support for a consistent security policy.  Don't want to fragment the namespace.

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

Do you have an opinion on this?
_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool