[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [btns] rfc 5387



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adding to Nico's response:

Nicolas Williams wrote:
> On Thu, Apr 23, 2009 at 04:15:59PM -0500, jb27 at cec.wustl.edu wrote:
>> Hello!  I am a student taking Internet Communications and our class is
>> just finishing up our "security" section and I have a few questions about
>> rfc 5387.
>>
>>
...
>> -In this RFC it is mentioned that obtaining a security certificate could
>> take a while.  I?ve never had to get one, so how long does it take?  Why
>> would it be necessary to skip?
> 
> That's unfortunate.  The problem isn't how long it takes to get a
> certificate (it could be as little as seconds with an online CA using
> something else for authentication -- think "kca", a kerberized CA), but
> the fact that deploying a PKI is usually difficult for a variety of
> reasones.

What it says is:

   ...Furthermore, obtaining and
   deploying credentials such as certificates signed by certification
   authorities (CA) involves additional protocol and administrative
   actions that may incur significant time and effort to perform.


The time and effort are related to the additional protocol and
administrative actions, i.e., setting up a PKI as Nico suggests above.
It's not just getting the certificate that takes time (it doesn't
particularly).

>> -From section 4, BTNS protects security associations after they are
>> established by reducing vulnerability to attacks from parties that are not
>> participants in the association.?  Doest this include MitM attacks?
> 
> Yes.

Agreed - *after* the BTNS association is established, it does protect
from further MITM attacks.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoAsvQACgkQE5f5cImnZrslrACg3WxY5d9leCB1bUi1V7wwrGer
vd8AniqKtfL1TNYDU05ikdM4A6rK7d7e
=4nuR
-----END PGP SIGNATURE-----

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.