RE: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only A Password) to Informational RFC

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only A Password) to Informational RFC

Glen, I have to agree with Dorothy's comment.  This method should
provide for channel binding support.  I find your unsubstantiated
assertion that doing so wouldbe be absurd uncompelling.

You claim that channel bindings are poorly defined.  I believe that
draft-ietf-emu-chbind brings us most if not all of the way there for
some important use cases.  However if you take a look at that draft,
you'll find that it's a lot better defined for the case where an EAP
method will transport the channel binding than for the case where a
secure association protocol is used.

In particular:

1) The secure association protocol by its nature happens after the
access-accept.  I've already started a session--told the peer to go
ahead with things before channel binding can be confirmed.  It's not
clear in existing secure association protocols where the EAP server gets
to interact with the peer again in order to tell it that channel binding
verification has failed.
So, it is unclear that the primary purpose of channel binding can be
performed in this case.

2) The document does not define sufficient messaging to community with
an AAA server to perform channel binding in a secure association
protocol.

So, basically, I think for channel binding to work  it needs to be
available in the method.

Moreover, whether channel binding is critical in a given deployment is
not actually dependent on whether the methods used in that deployment.
It's dependent on whether a deployment has multiple situations where a
peer could be significantly disadvantaged by authenticating to the wrong
NAS.  So, I cannot see good criteria for deciding when to add channel
binding and when not to add channel binding to new proposed methods.

Certainly, part of this is that I'm working on an EAP deployment where
channel binding is absolutely critical to the security of the
environment.  Especially since I don't see how to actually make it work
with a secure association protocol, I'm strongly in favor of a
requirement to support channel binding in new methods.

--Sam

Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

On Mar 1, 2010, at 8:34 AM, Joe Baptista wrote:
> Please remember the Kaminsky dns bug did not identify a security problem with the DNS but the UDP transport.

The problem Dan Kaminsky exploited is a known weakness in the DNS protocol, specifically that a 16-bit
identifier space is too small. 

> DNScurve fixes the problem today without having to spend 15 more years getting it right.

Not really.  Ignoring for the moment that there is a limited amount of deployed software that supports
DNScurve, DNScurve addresses the DNS protocol problem by protecting the channel of communication. It
doesn't actually protect DNS data.

> And it does not cost a fortune to implement.

How much did it cost you to implement DNScurve?  DId you make your code open source or otherwise available?

> And DNSSEC does not solve the UDP issue.

Actually, DNSSEC does address the DNS protocol issue by ensuring any modification to DNS data can be
identified.  In the DNSSEC world, it no longer matters how you get the DNS data or what channel the data comes
over or how secure that channel is.  The same is not true of DNScurve.

> And that is the problem DNScurve fixes NOW.

DNSSEC is already deployed in 12 top-level domains and the root is in the process of being signed.  Multiple
interoperable implementations of DNSSEC exist in production software.

> Together let's exercise some common sense and support draft-dempsky-dnscurve-01.

As has been pointed out on several occasions, DNSSEC and DNScurve are not mutually exclusive.  Of course, if
you implement DNSSEC, the protections provided by DNScurve are superfluous (and the opposite isn't
true), but that doesn't stop anyone from deploying both.

Regards,
-drc

Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

On Mon, 1 Mar 2010, David Conrad wrote:
>
> DNSSEC is already deployed in 12 top-level domains

Add a half for .uk  It has a deliberately invalid DNSKEY this week,
full deployment next week.

Tony.
--

-- 
f.anthony.n.finch  <dot <at> dotat.at>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

On Mon, 1 Mar 2010, Tony Finch wrote:

>> DNSSEC is already deployed in 12 top-level domains
>
> Add a half for .uk  It has a deliberately invalid DNSKEY this week,
> full deployment next week.

There is more then the 12 in itar. From the top of my head: .br .us .museum and .pt,
and of course a large part of the reverse (all RIPE zones) and ENUM.

Paul

IETF Workshop on Broadband Home Gateways

During the 76th IETF meeting, the Transport Area sponsored a Broadband
Home Gateway BoF, called HOMEGATE. Since that time, interested IETF
participants have been working to narrow the scope of the draft charter
and to reach out to other Standards Development Organizations (SDOs) to
ensure that the planned work is complimentary and not overlapping with
their respective work.

To further that goal, the IETF's Transport and Internet Areas intend to
co-sponsor a two-day workshop on HOMEGATE between IETF-77 and IETF-78.
This workshop is slated to take place on April 20-21, 2010 in London,
England.

In order to reserve a properly sized meeting facility, it is important
for interested people to indicate their interest in attending AS SOON AS
POSSIBLE. Please do so at http://event.pingg.com/HomeGateLondonMtg

NOTE: Due to potential venue limitations and the desire to allow
participants from different stakeholder groups to be represented, physical
attendance may need to be limited. Attendance will be confirmed at a later
time (and certainly early enough for people to book reasonably priced
travel accommodations). Remote listening or participation facilities of
some sort will be available to all.

PLEASE INDICATE YOUR INTEREST NOW if you wish to attend this interim
meeting in person: http://event.pingg.com/HomeGateLondonMtg

In addition:

- You can find the HOMEGATE wiki at
http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE

- You should join the HOMEGATE mailing list at
https://www.ietf.org/mailman/listinfo/homegate

Thank you in advance for your interest and participation!

Regards,
Lars Eggert & Magnus Westerlund, Transport Area Directors
Jari Arkko & Ralph Droms, Internet Area Directors
_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

Phillip Hallam-Baker wrote:

> Moving to DNSSEC, regardless of the technical model does not eliminate
> the need for certificates or CAs. The purpose of EV certificates is to
> re-establish the principle of accountability.

I don't know what EV means, but anything human, including CA, is not
infallible, which is why PKI is insecure.

Is EV divine?

						Masataka Ohta

Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf

PKIgate

Phillip Hallam-Baker wrote:

> You can design a PKI to meet many different needs.

No, PKI can be designed for imaginary needs only with no real security.

> Identity is one purpose, but not a very useful one.

It is an example of imaginary security.

> If you want security from a
> PKI you will do better with a validation system that provides
> accountability.

Real accountability needs a real account with real *M*O*N*E*Y*
in it.

If you loss $1M by a wrong operation of a CA, the CA should be
able to compensated the amount of the loss, which is the
accountability.

*M*O*N*E*Y* is the reality.

Then, what if, a wrong operation of a CA causes $1000 loss for 1M
people?

Bankruptcy of the CA does not help the people.

A CA charging $2000 for 1M certificates may have $1000000000 in
its account and may be able to compensate $1000 loss of 1M people.
But, what the point of people paying $2000, only to receive $1000
compensation? It's better for the people not to pay anything to
the CA. What if, if the loss is $1M loss for 1M people?

The only thing serious CAs can do is to make the possibility of
wrong operation absolute ZERO, which is not human and costs
infinite amount of money, which makes the CAs not profitable.

On the other hand, less serious CAs do little, if not nothing, and
just sell imaginary security at low cost to people who really need
real security.

That's how PKI is designed and CAs work.

PKI is a system of fraud.

						Masataka Ohta