headers
Manuel Urueña | 4 Sep 2003 18:47
Picon

Re: New WG Last Call on the Threats Assessment

Hi,

Reviewing the threats document and the rest of the Rserpool info, I
think I have found one question not covered by the threats draft and I
don't know if it has been already discussed. The question is: What's the
trust relationship between PUs and ENRP servers? 

This is answered partially in the Threats draft in the 2.7 Requirement:
"ASAP needs to authenticate the ENRP server", but not in the other way.

There is one scenario where the ENRP server needs to trust a PU. Section
4.7 of ENRP draft explains how a PU tells a ENRP server that a PE is
unreachable. When an ENRP server receives a ENDPOINT_UNREACHABLE
message, "...MUST inmediately send a point-to-point ENDPOINT_KEEP_ALIVE
message to the PE in question." If many PUs send such messages, this may
lead to a DoS to the ENRP-PE connection.

This doesn't seem to be a very dangerous attack as KEEP_ALIVE messages
are small, but maybe could be documented so an ENRP server only sends
KEEP_ALIVE messages at certain rate. However, If I have understood
correctly, there is a problem related to the MAX-BAD-PE-REPORT counter.

An ENRP server SHOULD delete a PE from a pool even if it responds to
ENDPOINT_KEEP_ALIVE messages just because several ENDPOINT_UNREACHABLE
messages have been received. A rogue PU may just ask for all the PEs of
a pool and then send MAX-BAD-PE-REPORT+1 ENDPOINT_UNREACHABLE messages
for each PE to knock down the whole pool. Do I miss something?

Of course, if all PUs are trusted these attacks will never occur, but
IMHO that severely limits the number of PUs able to access to a pool.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Maureen.Stillman | 8 Sep 2003 15:51
Picon

Here are minutes of IETF #57

Sorry this is late.  Comments are always welcome.  

-- maureen

IETF #57
Reliable Server Pooling WG (rserpool)
Monday, July 16, 2003 9:00-11:30AM

CHAIRs:
Lyndon Ong <lyong <at> ciena.com> 
Maureen Stillman <Maureen.Stillman <at> nokia.com>

Summary: Some documents are now nearing completion, while most others have been updated to be consistent.  

Rserpool comparison document
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-comp-06.txt
John Loughney

Rserpool architecture document
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-arch-06.txt
Michael Tuexen

The Rserpool comparison draft and architecture draft have been updated with new information.  The
comparison draft now includes further description of rserpool and its relationship with DNS and Layer
4-7 switches in response to questions from the Transport Directorate.  The architecture draft has been
updated with clarification of the control vs. data channel identification and usage and failover
support using cookies and business cards.  

The plan is to do a 1 week WG last call on the comparison document (which was already approved in its previous
version) and a 2 week LC on the architecture.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maureen.Stillman | 8 Sep 2003 20:13
Picon

RE: New WG Last Call on the Threats Assessment

Thanks for the comments on the threat document.

I agree we should mention this threat in the threat document.  I'll add it.

Concerning how to respond to the threat, I have 3 suggestions:

1) Take care of it in ASAP in the client.  ASAP will prevent the flooding of
the ENRP server with endpoint unreachable messages by some mechanism that
needs to be defined.
2) Take care of it in ENRP.  I believe that this is already done.  ENRP does
not automatically take the unreachable message as a mandate to delete the PE
from the database.
3) Do both 1 and 2.

I'm not convinced that the right response is to require all PUs to be
authenticated.  I think ASAP should handle this and protect the ENRP
servers.  ENRP should also protect itself and be suspicious of any message
from the PU as already specified.

Comments?

-- maureen

-----Original Message-----
From: ext Manuel Urueña [mailto:muruenya <at> it.uc3m.es]
Sent: Thursday, September 04, 2003 12:47 PM
To: rserpool <at> ietf.org
Cc: Ong, Lyndon
Subject: Re: [Rserpool] New WG Last Call on the Threats Assessment
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maureen.Stillman | 15 Sep 2003 21:41
Picon

TLS cipersuites for Rserpool

Although we have reached consensus on TLS for securing the Rserpool
infrastructure, we have not discussed TLS cipher suites.  TLS has a very
long and growing list of ciphersuites.  They vary in strength.  Security
experts want strong security.  Application developers worry about
interoperability.  The answer to this is for applications to mandate a
ciphersuite along with one or more shoulds for backward compatibility.

I am including the SIP RFC 3261 security section as an example.
In the SIP specification there is the following text:

The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at
   a minimum by implementers when TLS is used in a SIP application.  For
   purposes of backwards compatibility, proxy servers, redirect servers,
   and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.
   Implementers MAY also support any other ciphersuite.

For Rserpool we need to secure the following:

PU <----> ENRP Server
PE <----> ENRP Server
ENRP server <-----> ENRP Server

I recommend Rserpool security text as follows (for ENRP and ASAP security
sections):

The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a minimum
by implementers of TLS for Rserpool.   For purposes of backwards
compatibility, ENRP SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Implementers MAY also support any other ciphersuite.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Peter Lei | 15 Sep 2003 22:59
Picon

Re: TLS cipersuites for Rserpool

Maureen,

I agree with mandating the AES-128-CBC/SHA cipher, but what
is the rationale for the SHOULD for the 3DES cipher?  What
"backward compatibility" is desired/required here?

thanks,
--peter

Maureen.Stillman <at> nokia.com wrote:
> I recommend Rserpool security text as follows (for ENRP and ASAP security
> sections):
> 
> The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a minimum
> by implementers of TLS for Rserpool.   For purposes of backwards
> compatibility, ENRP SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.
> Implementers MAY also support any other ciphersuite.
> 
> I'll get Eric Rescorla's advice about this TLS cipher suite being the right one
> to make mandatory to support and also his take on backward compatibility.  We
 > might not need this in ENRP assuming that everyone will write new code
 > for Rserpool infrastructure.
Permalink | Reply | 0 comments |
headers
bill | 16 Sep 2003 00:44

RE: TLS cipersuites for Rserpool

Ack, that is what I hate about upper level protocols defining lower
level protocol behaviors...

Ok, first by making "the new cypher on the block" the only MUST
implement we get into a situation where AES might become broken, and
therefor we have a problem.

Yes 3des isn't as nice (for many reasons) but I know that I have better
than 90 bits of security with it.  With only 4-5 years of research
agains AES, I am not sure about that (yes I have read B Schneier's work
on cracking AES - don't think it is practical, but I am not enough of a
mathematician to prove it).

Security protocols go out of their way to prove interoperation, IPsec,
TLS, etc. if it turns out that we can not just use these lower layer
protocols intelligently -- why have we bothered to define them

Bill

-----Original Message-----
From: rserpool-admin <at> ietf.org [mailto:rserpool-admin <at> ietf.org] On Behalf
Of Maureen.Stillman <at> nokia.com
Sent: Monday, September 15, 2003 12:41 PM
To: rserpool <at> ietf.org
Subject: [Rserpool] TLS cipersuites for Rserpool

Although we have reached consensus on TLS for securing the Rserpool
infrastructure, we have not discussed TLS cipher suites.  TLS has a very
long and growing list of ciphersuites.  They vary in strength.  Security
experts want strong security.  Application developers worry about
(Continue reading)

Permalink | Reply | 1 comment |
headers
Melinda Shore | 16 Sep 2003 14:43
Picon
Favicon

Re: TLS cipersuites for Rserpool

On Monday, September 15, 2003, at 06:44 PM, bill wrote:
> Ok, first by making "the new cypher on the block" the only MUST
> implement we get into a situation where AES might become broken, and
> therefor we have a problem.

This has been discussed fairly extensively in saag, and the
consensus was that AES should be mandatory-to-implement in
new protocols and what to do about 3DES was an open question.

A bigger problem than the possibility of a cipher being
compromised, I think, is that when you've got multiple ciphers
providing different degrees of protection you've got the
possibility of a bid-down attack, which is a protocol attack
and frankly more accessible.  If more than one cipher is
to be specified we need to be explicit about how they're
requested/signaled and to make sure that it's resilient against
that particular type of attack.

Melinda
Permalink | Reply | 0 comments |
headers
Qiaobing Xie | 16 Sep 2003 21:31

Re: TLS cipersuites for Rserpool

I guess this must have been talked about by others but I am just not
well informed about the answer - will there be any IPR ramifications
when we say RSERPOOL MUST use certain ciphersuite? My impression is that
a lot of ciphers contain IPR. If that is the case, does the "MUST" imply
that RSERPOOL can not be implemented without tripping over some cipher
IPR?

regards,
-Qiaobing

Maureen.Stillman <at> nokia.com wrote:
> 
> Although we have reached consensus on TLS for securing the Rserpool
> infrastructure, we have not discussed TLS cipher suites.  TLS has a very
> long and growing list of ciphersuites.  They vary in strength.  Security
> experts want strong security.  Application developers worry about
> interoperability.  The answer to this is for applications to mandate a
> ciphersuite along with one or more shoulds for backward compatibility.
> 
> I am including the SIP RFC 3261 security section as an example.
> In the SIP specification there is the following text:
> 
> The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at
>    a minimum by implementers when TLS is used in a SIP application.  For
>    purposes of backwards compatibility, proxy servers, redirect servers,
>    and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.
>    Implementers MAY also support any other ciphersuite.
> 
> For Rserpool we need to secure the following:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maureen.Stillman | 17 Sep 2003 17:22
Picon

RE: TLS cipersuites for Rserpool

It is my understanding that AES is free from IPR.  I saw a letter from the AES co-author Dr. Joan Daemen waiving
all rights posted on a NIST website.  I didn't save the URL.

-- maureen

-----Original Message-----
From: ext Qiaobing Xie [mailto:Qiaobing.Xie <at> motorola.com]
Sent: Tuesday, September 16, 2003 3:32 PM
To: Stillman Maureen (NVO-NIC/Ithaca)
Cc: rserpool <at> ietf.org
Subject: Re: [Rserpool] TLS cipersuites for Rserpool

I guess this must have been talked about by others but I am just not
well informed about the answer - will there be any IPR ramifications
when we say RSERPOOL MUST use certain ciphersuite? My impression is that
a lot of ciphers contain IPR. If that is the case, does the "MUST" imply
that RSERPOOL can not be implemented without tripping over some cipher
IPR?

regards,
-Qiaobing

Maureen.Stillman <at> nokia.com wrote:
> 
> Although we have reached consensus on TLS for securing the Rserpool
> infrastructure, we have not discussed TLS cipher suites.  TLS has a very
> long and growing list of ciphersuites.  They vary in strength.  Security
> experts want strong security.  Application developers worry about
> interoperability.  The answer to this is for applications to mandate a
> ciphersuite along with one or more shoulds for backward compatibility.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maureen.Stillman | 18 Sep 2003 21:30
Picon

RE: New WG Last Call on the Threats Assessment

Here is the text I propose to add to the threat document in response to your comments.  Any comments on this?

2.13 Flood of endpoint unreachable messages from the PU to the ENRP
server

These messages are sent by ASAP to the ENRP server when it is unable to
contact a PE.  There is the potential that a PU could flood the ENRP
server intentionally or unintentionally with these messages.

Effect: DOS attack on the ENRP server

Requirement: Need to limit the number of endpoint unreachable messages
sent to the ENRP server from the PU.

2.14 Flood of endpoint keep alive messages from the ENRP server to a PE

These messages would be sent in response to a flood of endpoint
unreachable messages from the PUs to the ENRP server.

Effect: Unintentional DOS attack on the PE

Requirement: ENRP must limit the frequency of keep alive messages to a
given PE to prevent overwhelming the PE.

-- maureen

-----Original Message-----
From: ext Manuel Urueña [mailto:muruenya <at> it.uc3m.es]
Sent: Thursday, September 04, 2003 12:47 PM
To: rserpool <at> ietf.org
(Continue reading)

Permalink | Reply | 2 comments |

Gmane