Subject: [ietf-tls] JXTA and TLS

From: Bill Yeager <[email-masked]>
Date: Wed, 13 Jun 2001 16:15:07 -0700 (PDT)

Hi Pete,

| > Our final implemenation will be "almost TLS" as specified in rfc2246
| > with the "p2p twist" that every client is also a server, and
| > vice-versa.
| 
| It's not really the question you were asking, but I'm curious to know
| what you mean by "almost TLS".  Do you just mean that each machine
| will be a TLS client and server at the same time (for different
| connections of course)?  Alternatively will you actually be changing
| the protocol?

This is a good question:

	1) Yes, each machine is a server and a client. 

	2) Changing the protocol? 

	First a brief intro to JXTA : 

	If we look at the JXTA protocols, we will see that all information
*describing* a peer is made known by the means of advertisements published by
each peer. These are in XML, and sent in JXTA messages, which are also in XML. 

	Peers themselves communicate within groups which we call peergroups. At
bootstrap time a peer is a member of the world peergroup. peergroups are
collections of peers that have mutual interests. Anyone can create a
peergroup, put in place the requirements to join, advertise the peergroups
existence (part of that peer's advertisement), and exchange content with
members using JXTA messages. JXTA messages are content neutral. 

	In order for peers in a peergroup to send/receive JXTA messages they use
pipes as a transport abstraction. These are not UNIX pipes. Rather, they are
advertisements by a peer to accept input for a specific purpose from other
peers in a peergroup. Pipe advertisements are underlying-transport neutral.
Pipes are uni-directional (for now), and a single input pipe can receive
output from more than one peer. This is very nice for instant messaging pipes. 

	If a peer has received an input pipe advertisement, then if it wishes to
communicate with the associated peer, which is only known by its peerID which
is part of the pipe advertisement, it uses pipe resolution to find the
originating end point. This is a huge discussion that I don't want to address
here.

	Over TCP/IP this results in binding to a remote [IP-address,port].

	So, how does TLS fit into this picture?
	
	Handshake: This is functionally the same.

	When a peer advertises its existence, the peer advertisement (XML) current
contains "<Security> TBD </Security>". My idea is to replace the TBD with at
least the supported crypto suites and the peer's certificate.

	An input pipe will be advertised as secure/insecure. Thus, after endpoint
resolution on a secure pipe, we have:

	PeerA == pipe1 ===> PeerB (PeerB advertised pipe1)

This is not enough to complete the handshake (unidirectional pipes).

	Thus during resolution, PeerA can pass a pipe advertisement, pipe2, to peerB.
Finally, we have
	
	PeerA == pipe1 ===> PeerB (PeerB advertised pipe1)
	PeerA <= pipe2 ===> PeerB

	At this time the TLS handshake completes (random numbers exchanged, premaster
secret computed, etc ..), the master key calculation is done, key material
exchanged, security parameters passed to record layer, etc, all of this
religiously following the TLS specification. I'm leaving out the details but
they are familiar to all of you. When this is all done, then the application
layers exchange data as per the TLS spec.

	So, is the handshake really the TLS handshake if the crptosuites and certs
are known beforehand through advertisements? I think this is the only real
difference.

	Sorry for being so brief. If this interests you, then sign up for the JXTA
security project and contribute. The hard problem we are now working on is how
to do distributed, signed certificates with or without CA's. When we are
without CA's, then something very similar to the PGP "Web of Trust" is being
designed where trust is really probabilistic, and based on personal knowledge
and recommendations from other peer group members. We want to apply trust to
data, and QOS, as well as to certs.

Bill

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: 13 Jun 2001 16:41:53 -0700

> least the supported crypto suites and the peer's certificate.
This seems problematic. The TLS cipher suite negotiation is protected
by the Finished messages. Unless this advertisement is itself secured
(you don't say yes or no) then you may be susceptible to downgrade
attacks (depending on precisely how you specify the ciphersuites
used in the TLS handshake).

More importantly, what value is being added by having this stuff
in the advertisement? TLS has a perfectly good mechanism for
exchanging cipher suites and certificates. Why subvert it?

-Ekr

---

---

From: Eric Murray <[email-masked]>
Date: Wed, 13 Jun 2001 16:35:16 -0700

On Wed, Jun 13, 2001 at 04:15:07PM -0700, Bill Yeager wrote:

[..]

> are known beforehand through advertisements?

Nope.  Then it's TLS-like, as you stated earlier.
And unless there's something analagous to the handshake hash to
authenticate the ciphersuites, there could be a downgrade attack.

IIRC, Eric Rescorla's book has a lot of info in it about
the various security design issues that were uncovered when SSL/TLS was
designed and what was done to address them.  It's probably worth
a read for those attempting to improve or adapt TLS.

Eric

---

---

From: Bill Yeager <[email-masked]>
Date: Wed, 13 Jun 2001 17:09:23 -0700 (PDT)

| More importantly, what value is being added by having this stuff
| in the advertisement? TLS has a perfectly good mechanism for
| exchanging cipher suites and certificates. Why subvert it?

The idea is why exchange something each time you want to communicate, when it
can be known before hand when you first contact a peer. Advertisements are
cached with a timeout. 

You are right that it might not be worth it in the end. And, your point is
well taken. The closer we stick to TLS, the more trusted our implementation
will be. Am I talking myself out of using advertisements?

Thanks for the input!

Bill

---

---

From: Bill Yeager <[email-masked]>
Date: Wed, 13 Jun 2001 17:16:42 -0700 (PDT)

| Nope.  Then it's TLS-like, as you stated earlier.
| And unless there's something analagous to the handshake hash to
| authenticate the ciphersuites, there could be a downgrade attack.

Good point. This is the HMAC as I recall. I need to reread the rfc here ... 

| IIRC, Eric Rescorla's book has a lot of info in it about
| the various security design issues that were uncovered when SSL/TLS was
| designed and what was done to address them.  It's probably worth
| a read for those attempting to improve or adapt TLS.

I'll do that. 

Thanks,

Bill

---

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 13 Jun 2001 21:48:57 EDT

Bill:

You should probably pay attention to the discussion about performing
the Mac after the Encryption.  The opposite of the TLS order.

- Jeff

 Jeffrey Altman * Sr.Software Designer      C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

---

From: Pete Chown <[email-masked]>
Date: Thu, 14 Jun 2001 11:40:44 +0100

Bill,

Other people have already pointed out the possibility of a downgrade
attack, but here are a couple more thoughts.

Firstly, cryptographic protocols are much more fragile than they look
(which is why I asked the question).  Usually security is only
achieved when the "recipe" is followed exactly.  The downgrade attack
is particularly nasty if you don't restrict the choice of ciphersuite,
because you could be tricked into using TLS_NULL_WITH_NULL_NULL.

Secondly, I would like to second Jeffrey Altman's call for these
protocols to be discussed in an IETF working group.  That way, these
issues can be looked at by lots of different people, hopefully
resulting in the best possible design.

-- 
Pete

---

---

From: Bill Yeager <[email-masked]>
Date: Thu, 14 Jun 2001 10:46:41 -0700 (PDT)

| Bill:
| 
| You should probably pay attention to the discussion about performing
| the Mac after the Encryption.  The opposite of the TLS order.

Thanks for the pointer. I was thinking about certs in advertisements on the
way home, and JXTA really needs this because they are to be used for more than
TLS. Lots of apps need certs, eg, JXTA email (a project to be soon proposed). 

Still, there is no need to put the crypto suites in the advertisement, and
maybe, one would do a cert refresh when TLS is required ...

Bill

---

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 14 Jun 2001 13:52:09 EDT

Bill

I'm also a little concerned about the "unreliability" of the JXTA
pipes.  It would be nice to have the secure pipes not require
reliability.

In addition, it is very important to me that Kerberos be usable
instead of certificates the the applications I am building on top of
JXTA.  This is because I want to secure my p2p communications with
Kerberos 5 User to User mode.

- Jeff

---

---

From: Bill Yeager <[email-masked]>
Date: Thu, 14 Jun 2001 11:34:33 -0700 (PDT)

| Firstly, cryptographic protocols are much more fragile than they look
| (which is why I asked the question).  Usually security is only
| achieved when the "recipe" is followed exactly.  The downgrade attack
| is particularly nasty if you don't restrict the choice of ciphersuite,
| because you could be tricked into using TLS_NULL_WITH_NULL_NULL.

We are going to restrict the choice of cipher suites by necessity. Right now,
our code base is small, and I'm not finding lots of voluteers to help make it
grow )-: (I don't mean to contradict myself with respect to Camellia. I've
known about Camellia for a long time).

And, certainly, it now makes good sense to use the HMAC to make sure such an
attack is not possible. I had not thought about it, and we will not put the
cipher suites in advertisements for sure. 

| Secondly, I would like to second Jeffrey Altman's call for these
| protocols to be discussed in an IETF working group.  That way, these
| issues can be looked at by lots of different people, hopefully
| resulting in the best possible design.

I "third" this. The only obstacle is work load. I'm looking at taking the next
rev of the specs and turning it into a draft-rfc. I've been involved with the
IETF for a long, long time, and really respect the work that gets done there.
You don't see my name many places wrt to the RFC space, but you will find lots
of apps out there that I've written based on the specs. 

Bill

---

---

From: Bill Yeager <[email-masked]>
Date: Thu, 14 Jun 2001 11:55:30 -0700 (PDT)

Jeff,

Can we continue this discussion on the [email-masked] mailing list?
It is becoming very relevant to the work will be going on there.

| I'm also a little concerned about the "unreliability" of the JXTA
| pipes.  It would be nice to have the secure pipes not require
| reliability.

Are you saying that you would like pipe/secure pipes not to require end-to-end
reliability? I don't think that can be a requirement by the very nature of p2p
networks. Connections can disappear anytime. Are we talking about the same
thing?

| In addition, it is very important to me that Kerberos be usable
| instead of certificates the the applications I am building on top of
| JXTA.  This is because I want to secure my p2p communications with
| Kerberos 5 User to User mode.

What is placed in the advertisement is peer dependent. I would love to have a
general scheme much like the IMAP capability command, with its AUTH=, and
AUTHENTICATE. 

THis is all new, and we need discussions to correctly bootstrap the security
part of JXTA. Right, and we really require input from IETF. This is becoming
more and more apparent with each message I receive from this list!

Bill

---

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 14 Jun 2001 15:12:58 EDT

> It is becoming very relevant to the work will be going on there.

Done.

> Are you saying that you would like pipe/secure pipes not to require
> end-to-end reliability? I don't think that can be a requirement by
> the very nature of p2p networks. Connections can disappear
> anytime. Are we talking about the same thing?

We are talking about a different thing.  TLS assumes that the
underlying connections (pipes) have the same or better reliability
provided by TCP/IP.  In JXTA, this assumption does not hold.  

As far as I can tell but I may be off a bit here, the JXTA pipe model
in addition to being only unidirectional provides UDP reliability.
Not only do we not know whether or not all of the messages that were
sent have been received, but we cannot ensure that they were received
in the correct order.  

JXTA also allows multiple senders to attach to a single input pipe.
Therefore, it is possible for message streams to be mixed.  The JXTA
security model is certainly going to have to take this into account.

For a TLS streaming model to work, then we must require TCP style
reliability with regard to message delivery.  For pipes that do not
have these characteristics (and applications that do not require them)
we will need a different model that simply encrypts and signs
individual messages without regard to order.  This will clearly affect
the cipher suites that can be used.

> more and more apparent with each message I receive from this list!

Its may not be too late to schedule a BOF for London (August) although
we can certainly push it off until IETF 52 (December).

- Jeff

---

---

From: Ben Laurie <[email-masked]>
Date: Thu, 14 Jun 2001 20:32:16 +0100

> security model is certainly going to have to take this into account.

This doesn't have to be visible at the application layer, of course
(that is, you can use secure one-to-one pipes underneath but make it
look at the application level like there are multiple senders to a
single pipe).

> the cipher suites that can be used.

I'm still confused by what you are asking for - do you _want_ this kind
of transport, or think it is necessary, or want to avoid it, or what?

> we can certainly push it off until IETF 52 (December).

I'd certainly come to one in London.

Cheers.

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 14 Jun 2001 15:39:09 EDT

> of transport, or think it is necessary, or want to avoid it, or what?

I believe that JXTA must provide both reliable and unreliable secure
pipes as part of the core protocols.

> I'd certainly come to one in London.

I would be happy to meet you there whether we have one or not.

- Jeff

---

---

From: Ben Laurie <[email-masked]>
Date: Thu, 14 Jun 2001 21:05:31 +0100

> pipes as part of the core protocols.

OK. The obvious way to do unreliable would be to use OpenPGP, wouldn't
it? At least, assuming PKC is considered to be a good idea (I think it
is).

Actually, is there any point in going beyond IPSEC/ISAKMP?

> I would be happy to meet you there whether we have one or not.

I'll be there! Even remembered to register :-)

Cheers,

Ben.

---

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 14 Jun 2001 16:18:21 EDT

> it? At least, assuming PKC is considered to be a good idea (I think it

OpenPGP is certainly the obvious choice for a distributed trust
model.

> Actually, is there any point in going beyond IPSEC/ISAKMP?

Maybe not.  I'm not really sure yet.  I'm still playing around with
different models of peer groups. 

> I'll be there! Even remembered to register :-)

:-)  I just reserved a room.  Now to find a flight.....  

See you there.

- Jeff

---

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 14 Jun 2001 14:04:31 -0700

> more and more apparent with each message I receive from this list!

There is also onging work defining kerberos ciphersuites for TLS that support user
to user mode.  (A new draft should be out soon).

Joe

---

---

From: Bill Yeager <[email-masked]>
Date: Thu, 14 Jun 2001 14:33:34 -0700 (PDT)

Jeff,

| As far as I can tell but I may be off a bit here, the JXTA pipe model
| in addition to being only unidirectional provides UDP reliability.
| Not only do we not know whether or not all of the messages that were
| sent have been received, but we cannot ensure that they were received
| in the correct order.  

This has had lots of internal discussion as you can imagine. I think
reliability is extremely important. To that end, reliability layer on top of
pipes has been proposed. In the simple sense, it is an ACK of data sent, and a
guarantee of the correctness of order. This could be TFTP like, or a
generalization. Sigh ... 

But, I have argued that if a pipe has TCP/IP as the underlying transport, and
since this is known to the pipe end-points, we should take advantage of that
to have both reliable, and bi-directional pipes with almost no software
changes. I don't see this as controversial at all. I've mentioned it on
[email-masked]. 

| JXTA also allows multiple senders to attach to a single input pipe.
| Therefore, it is possible for message streams to be mixed.  The JXTA
| security model is certainly going to have to take this into account.

Yes and no. If we were using UDP/IP, sure, and what a mess for the dispatcher!
In the current implementation, this is not done if the underlying transport is
TCP/IP. These pipes are connection based, and handled like a primitive http
server on a jxta message by message basis in a single input thread with a FIFO
for connections. Listen, connect, read message, dispatch message, close,
listen, connect ... So, for TLS, if one maintained sessions across messages,
this should work. That needs to be fixed! 

I understand there is a project brewing to change the JXTA end-point resolver
to solve this problem. Bi-directional, reliable byte streams end-to-end.

Does this help?

| 
| Its may not be too late to schedule a BOF for London (August) although
| we can certainly push it off until IETF 52 (December).

Let me take this up with my management. London may be possible, and otherwise,
December is a must.

Bill

---

---

From: Bill Yeager <[email-masked]>
Date: Thu, 14 Jun 2001 14:36:56 -0700 (PDT)

| OpenPGP is certainly the obvious choice for a distributed trust
| model.

I'm checking this out as you read this message. I can send you another ref on
trust by recommendation, if you are interested. It resembles very closely the
PGP Web of Trust.

Bill

---

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 14 Jun 2001 18:06:51 EDT

> changes. I don't see this as controversial at all. I've mentioned it on

This will work as long as A <--> B but it will break down if 
A <--> C <--> B.  Do we really want to have a different security model
for different kinds of pipes?

> to solve this problem. Bi-directional, reliable byte streams end-to-end.

It only helps only if it going to be the mandatory to implement pipe.
However, I see a large majority of JXTA peers using an HTTP proxy in
the near future.  And of course, in that scenario any discussions we 
have about using TCP/IP go out the window.

---

---

From: Ben Laurie <[email-masked]>
Date: Thu, 14 Jun 2001 23:15:59 +0100

> guarantee of the correctness of order. This could be TFTP like, or a

Reinventing the wheel is a bad thing. If you want reliable, why not use
existing underlying reliable transports?

BTW, I didn't notice any mention of multicast in JXTA, which seems like
a shame. Any plans there?

Cheers,

Ben.

---

---

From: Pete Chown <[email-masked]>
Date: Fri, 15 Jun 2001 12:11:53 +0100

> general scheme much like the IMAP capability command, with its AUTH=, and

Isn't this insecure for the same reason as the altered TLS?  An
attacker could force you to use the weakest supported protocol.
Suppose your systems supported TLS and a plaintext password protocol
called PLAIN.  The server sends:

AUTH = TLS PLAIN

The client supports both these too, so normally it would respond TLS.
However if an attacker changed the message to read:

AUTH = PLAIN

the client would respond PLAIN and the data sent could be compromised.

(I suppose this wouldn't be a problem if the client had a QoS
parameter saying that a certain level of security was required.  Then
it could refuse to connect if the only method on offer was PLAIN.)

-- 
Pete

---

---

From: Ben Laurie <[email-masked]>
Date: Fri, 15 Jun 2001 12:33:58 +0100

> it could refuse to connect if the only method on offer was PLAIN.)

If you aren't prepared to support the weakest protocol, why did you
advertise it?

Cheers,

Ben.

---

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 15 Jun 2001 8:08:52 EDT

> it could refuse to connect if the only method on offer was PLAIN.)

Yes.  This has the same problems.  At some point in the authentication
process the list of offered methods must be protected.  If not, you
are open to a downgrade attack.  

The problem with QoS parameters is that they are inevitably hard
coded.  What is secure today may not be secure tomorrow after some new
discovery.  The important issue is whether or not the communication
channel is being tampered with.

- Jeff

---

---

From: Bill Yeager <[email-masked]>
Date: Fri, 15 Jun 2001 14:40:31 -0700 (PDT)

| This will work as long as A <--> B but it will break down if 
| A <--> C <--> B.  

The problem is well understood. And, "C" in the middle reminds me of the WAP
gateway fiasco. It really hurt the WAP people. JXTA cannot repeat that error.

| Do we really want to have a different security model
| for different kinds of pipes?

No.

| It only helps only if it going to be the mandatory to implement pipe.
| However, I see a large majority of JXTA peers using an HTTP proxy in
| the near future.  And of course, in that scenario any discussions we 
| have about using TCP/IP go out the window. 

As I said above, end-to-end TCP/IP is a must for secure pipes. We need to make
sure that near future means just that, and argue strongly against any proxies
that might break the integrity of a secure connection.

Firewalls are a pain though if you cannot use SOCKS. In this case, HTTP is the
only alternative I personally know about for traversal.

Bill

---

---

From: Bill Yeager <[email-masked]>
Date: Fri, 15 Jun 2001 14:42:55 -0700 (PDT)

| Reinventing the wheel is a bad thing. If you want reliable, why not use
| existing underlying reliable transports?
| 
I totally agree. I've fought this battle many times, and fortunately won. The
last time was in the WAP Forum where Sun and MS (can you believe) teamed up to
kill a proxied WAP/TCP large file transport. WAP was going to sort of reinvent
TCP between the phone and the gateway!

| BTW, I didn't notice any mention of multicast in JXTA, which seems like
| a shame. Any plans there?

Multicast is used on the localnet as an initial attempt at discovery. 

Bill

---

---

From: Bill Yeager <[email-masked]>
Date: Fri, 15 Jun 2001 14:47:35 -0700 (PDT)

| Isn't this insecure for the same reason as the altered TLS?  An
| attacker could force you to use the weakest supported protocol.

For AUTH à l'IMAP you are right. An attacker could with some effort pretent to
be your server, and get your password in plain text.

But, one might only offer secure authenticators, AUTH=DH,KERBEROS. Or as you
have said

| 
| (I suppose this wouldn't be a problem if the client had a QoS
| parameter saying that a certain level of security was required.  Then
| it could refuse to connect if the only method on offer was PLAIN.)

Good that you point out these problems (-:

Bill

---

---

From: David Hopwood <[email-masked]>
Date: Fri, 15 Jun 2001 23:23:01 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Bill Yeager wrote:
> Firewalls are a pain though if you cannot use SOCKS. In this case, HTTP
> is the only alternative I personally know about for traversal.

"RFC 3093: Firewall Enhancement Protocol" is a must-read reference for
anyone planning to do this (be sure to note the publication date).

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 15 Jun 2001 20:20:11 EDT

> only alternative I personally know about for traversal.

I come from a world in which IP is not the only network protocol.  In
fact, I don't see why the JXTA security model needs to be tied to IP
at all.  I want to design and implement a security model that works
for both streams and asynchronous messaging.  One that will work just
as well over an HTTP proxy (via client polling) as over an IPSEC
secured TCP/IP socket.

- Jeff

---

---

From: Ben Laurie <[email-masked]>
Date: Sat, 16 Jun 2001 11:09:38 +0100

> only alternative I personally know about for traversal.

NAT? But I have to say I am not keen on the whole concept that firewalls
are things you should find ways to avoid. They are there for a purpose,
you know! The right answer is to make sure it is possible to run
appropriate stuff on a firewall to give appropriate access, if the
appropriate people think its a good idea, surely?

Cheers,

Ben.

---

---

From: Ben Laurie <[email-masked]>
Date: Sat, 16 Jun 2001 11:10:04 +0100

> Multicast is used on the localnet as an initial attempt at discovery.

I meant multicast pipes.

Cheers,

Ben.

---

---

From: Jeffrey Altman <[email-masked]>
Date: Sat, 16 Jun 2001 8:58:37 EDT

> appropriate people think its a good idea, surely?

My feeling on this subject is that firewalls are nothing more than a 
security blanket that provide a false sense of security.  The
appropriate place for managed access controls is at the end points;
not somewhere in the middle of the cloud.  Firewalls do not prevent 
someone from running the application of their choice.  It only makes
it a little more difficult.  Once there is one open window any and 
all applications will get through.

---

---

From: Ben Laurie <[email-masked]>
Date: Sat, 16 Jun 2001 17:14:33 +0100

> all applications will get through.

Generally speaking, I agree. Most firewalls are a poor substitute for
correctly setting up your machines, and where they aren't they're
redundant.

However there is a class of firewall that is definitely not redundant,
namely non-routing hosts that allow internal machines to connect
outwards (via SOCKS or NAT, preferably the latter, IMO) but do not allow
the reverse. There are sometimes a few things you'd like to come inwards
over such firewalls, mail being an example, SSH being another and maybe
JXTA is yet another. These are normally handled by appropriate
_application-level_ gateways. And that's what I'm talking about.

Cheers,

Ben.

---