Subject: [AAA-WG]: Can CER from unknown hosts cause Peer Table entries

From: <[email-masked]>
Date: Tue, 5 Mar 2002 17:31:01 +0200

Hi,

Referring section 5.3 on capabilities-exchange which says,

"If the local policy permits receiving CERs from unknown hosts, a successful CEA MAY be returned."
I have the following queries, if someone can clarify.

If a node accepts CER from an unknown host and returns a successful CEA, does it amount to a peer discovery and can an entry be made in the peer table. 
If this is possible, I have further questions. The information present in a CER may not be sufficient to make a peer table entry. For example the CER does not contain the port on which the peer listens for connections, the transport protocols that the peer supports etc.

Thanks in advance.

Regards,
Kishore

-----Original Message-----
From: ext Walker, Jesse [mailto:[email-masked]]
Sent: 05. March 2002 17:11
To: 'Bernard Aboba'; [email-masked]
Subject: [AAA-WG]: RE: Why NASREQ Key Distribution is insecure (fwd)

Thanks Bernard,

This is a very good paper that will help people understand the issues. This
has been one of the most influential papers ever published to help form the
thinking about these protocols in the cryptographic community. This is some
of the most inspired and original work by two of the very best
cryptographers in the world.

One thing to note about 3PP is, however, that almost as soon as it was
published somone pointed out a problem with it, even though the proof of
security is entirely valid! The problem arises because one of the
assumptions is wrong. The wrong assumption is that an adversary could use
the Test operation only once and then only at the "end of the game." Real
adversaries don't restrict themselves in this way. So Bellare and Rogaway
fixed this assumption and their proof and went on, although they never
published this. Victor Shoup has published one way to fix it in
http://shoup.net/papers/skey.pdf.

The point is that key distribution is a damnably hard and subtle problem in
ways that are not apparent even to the very best experts in the world. My
recommendation to 802.11 has been and is that we need to take any one of
several protocols that the crypto community has confidence in and then adapt
it to our setting, and I make the same appeal now to AAA, because fixing
this problem is outside the scope of 802.11's charter, but they cannot
succeed in fixing their security without getting key distribution correct.
Trying to roll our own is just a disaster waiting to happen.

-- Jesse

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Monday, March 04, 2002 9:43 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Why NASREQ Key Distribution is insecure (fwd)

Here is a paper by Bellare and Rogaway paper on provably 
secure 3 way key distribution which may relate to this issue.

http://www.drizzle.com/~aboba/AAA/3pkd.pdf

On Mon, 4 Mar 2002, Bernard Aboba wrote:

> This is followup documentation on the issue posted to the list
> earlier. 
> 
> ---------------------------------------------------------------------
> From: Jesse Walker <[email-masked]>:
> To:   [email-masked]
> 
> 
> >Given that the AS and AP trust each other (assumed), why
> >is a reasonable cryptographic protocol (such as CMS or even IPSec) is
> >insufficient to protect the transfer of a STA-AP session key from the AS
to
> >the AP?
> 
> There has been in fact ample discussion around exactly these points. There
> is, for instance, the whole key handoff discussion, of which AS-AP handoff
> is a special case. As a second example, there is the flap around the
> Arbaugh-Mishra 802.1X paper, which echos many of our key handoff
> discussions, and which we have also discussed.

---

From: David Spence <[email-masked]>
Date: Tue, 05 Mar 2002 11:38:54 -0500

> If a node accepts CER from an unknown host and returns a successful CEA, does it amount to a peer discovery and can an entry be made in the peer table.

Yes, this means that you have either been "discovered" or redirected to. 
You will need to decide whether you want to accept a connection from the
originator of the CER.  I think there are definite security concerns here
which I will raise in a separate message.

> If this is possible, I have further questions. The information present in a CER may not be sufficient to make a peer table entry. For example the CER does not contain the port on which the peer lis…

If, by a peer table entry, you mean do you have enough information to create
an entry that would allow you to recreate the connection if the connection
you are establishing now gets broken, the answer is no.  In this case, he
wanted to talk to you, so it's his responsiblity to re-establish the
connection.  As far as the current connection is concerned, however, you
don't need any further information.  You don't need the port number on which
he listens.  You know what transport protocol is in use for this
connection.  And whatever security needs to be established has already been
established, you hope, because, by CER/CEA time, the security stuff has
already happened.

>...