Re: Risk of Laptop Seizure by Customs or Border Patrol Officers ...

[Joe Abley]

On 10-Nov-2006, at 02:35, Michel Py wrote:


Michel Py wrote:
Besides, there are several ways to carry confidential info while
flying. Here's an example: They'll look at your laptop, but will
not bother looking at the 4GB SD card you have in your digital  
camera



Lyndon Nerenberg wrote:
These days it's called an 'iPod'.


An iPod is a lot more suspicious, IMHO.


Apparently!

  http://forums.worldofwarcraft.com/thread.html? 
topicId=11211166&pageNo=1&sid=1



Joe


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)

[Michael . Dillon]

> We need to 
> resend in 30 seconds, perhaps, and if mumble time units elapse 
> without successful delivery we need to initiate a response to the 
> sender indicating that s/he should try another communication channel 
> while we continue to retry this one.

Waiting 30 seconds would be unwise in the scenario described.
Instead of waiting, the sending application should be sending
2 or 3 copies of the message via different routes to ensure
that it gets there as quickly as possible.

For existing models on how to accomplish this in IP, you 
should look at the financial services industry where tickers
and other market datafeeds must get to the recipient as fast
as possible because millions of dollars are at stake. In this
environment, datafeeds are sent via multicast. Each packet is
duplicated and sent via two different multicast trees which 
travel over infrastructure which is entirel discontiguous, 
i.e. separacy is enforced right down to the physical layer.

It works well and something like this is likely to be the
right way to handle critical emergency communications. Note
that an important aspect of this type of solution is that it 
defeats IP routing's concept of the single best path for a packet.
This means that if you don't need the multiple recipients that
a market data feed requires, you might find a way to do something
similar with MPLS TE that is more suited to emergency comms.

> Those experts aren't in the ITU, and the ITU at this point doesn't 
> have the expertise to even say what was said in my long paragraph 
> above. 

And the ITU does not have applications layer experts which
is what you need to design a communications solution for some
very specific and very important applications layer requirements.
Some people are assuming that lower level protocols need to
be *fixed* to enable this but I do not agree that is the case.

> I do believe that having a requirements-generating working group is a 
> good thing.

Yes. And get some other applications domain experts to contribute
such as people from the financial industry or SIAC. IMHO, the
financial industry treats this matter with much greater care
and importance than the defense and security sector because in
the financial services industry, the impact of communications
failures is immediate and can be severe. Unlike the defense and
security sector who must deal with events sporadically, in financial
services the events are numbered in transactions per second.

--Michael Dillon


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Improving Security with Encryption

[King, Kimberly S.]

> Fred Baker wrote:
> What I would suggest is that people encrypt confidential
> information on their laptops, and perhaps the entire laptop.

I strongly agree and my entire laptop is encrypted.  Perhaps people could
consider suggesting to their management that data protection is critical and
disk encryption is a simple effective step.  Sometimes managers aren't aware
of the tools (or risks) available and maybe it is up to the technical
community to inform them and help protect sensitive information (e.g.,
individuals data, company and client confidential data, etc.). 

Kimberly

 

-Original Message-
From: [EMAIL PROTECTED]
To: Fred Baker; [EMAIL PROTECTED]
Cc: ietf@ietf.org
Sent: 11/10/2006 12:34 AM
Subject: RE: Risk of Laptop Seizure by Customs or Border Patrol Officers ...

>> JORDI PALET MARTINEZ wrote:
>> http://www.acte.org/resources/press_release.php?id=91

Ah, our brilliant government in its infinite wisdom


> Fred Baker wrote:
> What I would suggest is that people encrypt confidential
> information on their laptops, and perhaps the entire laptop.

I would not recommend encrypting the entire laptop. As George Carlin
would say (*), border service agents with a double-digit IQ and a
triple-digit income might think that if dude encrypts the entire laptop,
dude must really have top-secret stuff on it, while the only two
confidential files dude has on his laptop are the payroll spreadsheet
showing how much more dude makes compared to his office buddies and
dude's mistresses phone numbers (one in each city, needs a database to
keep track of). No need to trigger un-necessary scrutiny: Traveling
Terrorist's 101: do not look, dress or act like one.

Besides, there are several ways to carry confidential info while flying.
Here's an example: They'll look at your laptop, but will not bother
looking at the 4GB SD card you have in your digital camera, which
happens to be a perfectly good plug-and-pray disk for any computer, PC
or Mac. I have stored Excel and PowerPoint files both in and out of the
directories used for pictures and it never bothered any camera I had in
my hands.

And even if they do look at it, there are ways to embed your
confidential data within pictures. You need to use a lossless
compression format such as TIFF. If done correctly, on a digital camera
with a noisy CCD at high ISO settings, there is no way to find out that
the least-significant bit of the picture contains actual data. A
5-megapixel 24-bit picture is 15MB, out of which 1.8MB are useable in
theory and 300KB in practice. In short: configure the camera to TIFF,
noise reduction to off, ISO 400 or higher.

Heck, you don't even need a laptop. Just a digital camera.

Michel.


(*) Info: recorded _before_ 9-11-01
(*) Warning: absolutely politically incorrect and rude language.
(*) If you have a problem with the "F" word, do NOT click the link
below.
(*) http://www.youtube.com/watch?v=BZwMz2bsbNY


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Improving Security with Encryption

[James M. Polk]

At 09:58 AM 11/10/2006 -0500, King, Kimberly S. wrote:

> Fred Baker wrote:
> What I would suggest is that people encrypt confidential
> information on their laptops, and perhaps the entire laptop.

I strongly agree and my entire laptop is encrypted.  Perhaps people could
consider suggesting to their management that data protection is critical and
disk encryption is a simple effective step.


Is *everything* on your laptop work related, or do you (speaking generally) 
sneek a few personal files on the laptop.


If the latter, what are you plans on transferring that info to/from other 
personal devices, such as a hime computer, a PDA, or another device?


If this policy you suggest is taken only a little bit too zealously, your 
company will mandate encrypting your work files, create and perhaps enforce 
a policy that only work related files are on your work owned laptop, and 
prevent things like synchronizing your calendar on your laptop and PDA, or 
other useful and harmless activities...


I don't like this slippery slope (of my org making this choice)


Sometimes managers aren't aware
of the tools (or risks) available and maybe it is up to the technical
community to inform them and help protect sensitive information (e.g.,
individuals data, company and client confidential data, etc.).

Kimberly



-Original Message-
From: [EMAIL PROTECTED]
To: Fred Baker; [EMAIL PROTECTED]
Cc: ietf@ietf.org
Sent: 11/10/2006 12:34 AM
Subject: RE: Risk of Laptop Seizure by Customs or Border Patrol Officers ...

>> JORDI PALET MARTINEZ wrote:
>> http://www.acte.org/resources/press_release.php?id=91

Ah, our brilliant government in its infinite wisdom


> Fred Baker wrote:
> What I would suggest is that people encrypt confidential
> information on their laptops, and perhaps the entire laptop.

I would not recommend encrypting the entire laptop. As George Carlin
would say (*), border service agents with a double-digit IQ and a
triple-digit income might think that if dude encrypts the entire laptop,
dude must really have top-secret stuff on it, while the only two
confidential files dude has on his laptop are the payroll spreadsheet
showing how much more dude makes compared to his office buddies and
dude's mistresses phone numbers (one in each city, needs a database to
keep track of). No need to trigger un-necessary scrutiny: Traveling
Terrorist's 101: do not look, dress or act like one.

Besides, there are several ways to carry confidential info while flying.
Here's an example: They'll look at your laptop, but will not bother
looking at the 4GB SD card you have in your digital camera, which
happens to be a perfectly good plug-and-pray disk for any computer, PC
or Mac. I have stored Excel and PowerPoint files both in and out of the
directories used for pictures and it never bothered any camera I had in
my hands.

And even if they do look at it, there are ways to embed your
confidential data within pictures. You need to use a lossless
compression format such as TIFF. If done correctly, on a digital camera
with a noisy CCD at high ISO settings, there is no way to find out that
the least-significant bit of the picture contains actual data. A
5-megapixel 24-bit picture is 15MB, out of which 1.8MB are useable in
theory and 300KB in practice. In short: configure the camera to TIFF,
noise reduction to off, ISO 400 or higher.

Heck, you don't even need a laptop. Just a digital camera.

Michel.


(*) Info: recorded _before_ 9-11-01
(*) Warning: absolutely politically incorrect and rude language.
(*) If you have a problem with the "F" word, do NOT click the link
below.
(*) http://www.youtube.com/watch?v=BZwMz2bsbNY


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Risk of Laptop Seizure by Customs or Border Patrol Officers ...

[Hallam-Baker, Phillip]

 

> From: Michel Py [mailto:[EMAIL PROTECTED] 

> I would not recommend encrypting the entire laptop. As George 
> Carlin would say (*), border service agents with a 
> double-digit IQ and a triple-digit income might think that if 
> dude encrypts the entire laptop, 

You can do this on Windows with a couple of mouse clicks. 

My Documents->Preferences->General->Advanced

Encrypt Directory contents.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Guidance for AAA Key Management' to BCP (draft-housley-aaa-key-mgmt)

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Russ Housley [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 08, 2006 10:48 AM
> To: Joseph Salowey (jsalowey); ietf@ietf.org
> Subject: RE: Last Call: 'Guidance for AAA Key Management' to 
> BCP (draft-housley-aaa-key-mgmt) 
> 
> Joe:
> 
> >I'm not really clear on the purpose of the document.  What does it 
> >apply to?  Does it require changes to existing AAA 
> protocols? Does it 
> >add new requirements to EAP methods that are not in RFC3748? 
> It would 
> >probably be good to reference 3748 when it applies to a 
> requirement in 
> >this document (such as replay protection, strong fresh 
> session keys, etc.).
> 
> This is really asking for two things, if I am reading it properly.
> 
> First, you seem to want some additional text in the 
> Introduction about the things to which the BCP will apply.  
> The intent was broad applicability.  It is intended to become a BCP.
> 
[Joe] OK

> Second, you seem to want a tighter coupling to EAP.  While 
> EAP is clearly an important aspect of AAA, the requirements 
> are intended to be met by the system as a whole.  Maybe I am 
> missing something in your comment, but I do not want a 
> tighter binding than necessary.
> 

[Joe] Neither do I. Would it be useful in the document to show how these
requirements are met/not met/conditionally met with an existing AAA key
management protocol such as RADIUS/EAP/802.11?

> >What does AAA key management protocol refer to?  Is it the 
> combination 
> >of EAP, AAA and Security Association Protocol?
> 
> Other Last Call comments suggest that a broad interpretation 
> is appropriate.  All three of these are certainly included, 
> but other things might be included too.
> 
[Joe] OK, we might want to clarify that AAA key management protocol
involves more than just the AAA protocol.

> >2. Strong fresh session keys
> >
> >In this section it is not clear what the subject session 
> keys are.  It 
> >is not clear to me what role the AAA protocol plays in 
> "ensure that the 
> >keying material supplied as an input to session key 
> derivation is fresh"
> 
> Bernard and I discussed this at great length with Sam before 
> IETF Last Call.  In this context, "session" is a vague.  I 
> think it is vague because of the large number of places where 
> AAA is employed.  This document inherits this purposeful 
> vagueness too.
> 
[Joe] OK, If I understand correctly this would refer to some yet to be
defined protocol that does not use EAP?


> >Also wouldn't key caching be relevant on the EAP server 
> rather than the 
> >"AAA server"?
> 
> Is "AAA/EAP server" better?
> 
[Joe] Yes.

> 
> >3.  Authenticate all parties
> >
> >What is the AAA key management protocol?  It seems that some of this 
> >section is about validating keys are used within they 
> correct context 
> >and not necessarily authentication.  Maybe part of this 
> section should 
> >belong with the context binding section.
> 
> I do not understand your point here.
> 
[Joe] I think I wanted to get at that the link between authentication
and authorization may not be direct.  As the section alludes to, the
identity that is authenticated may not be useful for authorization. In
this case it is not necessarily authentication of identity that is
important, but rather the binding of the entity to authorization
information (such as a key in existing systems).

> 
>
>5. Unique Key Names
> >
> >This section states "the key name MUST NOT be based on the keying
> >material itself." 802.11i uses this technique; are there 
> vulnerabilities
> >associated with this?
> 
> Maybe I have forgotten too much about 802.11i.  Please give 
> your example.
> 
> Yes, there are several way to base the name on the key value that 
> discloses information about the key value.  We do not want the key 
> name to aid the attacker in a brute force search by trimming 
> the search space.
> 

[Joe] The PMKID is a function of the PMK and the addresses of the
participants and may be vulnerable to what you describe.  
> 
>
> >6. Bind key to its context
> >
> >In this section it is not clear what the "protocol" is or how the
> >binding would occur.  What is meant by "The manner in which 
> the keying
> >material is expected to be used."
> 
> Is it an integrity key, an encryption key, a key derivation key, a 
> key-encrypting key, etc?  In which protocol will the key 
> perform this role?
> 
[Joe] OK makes sense. 
> 
> >7. Security considerations
> >
> >The first paragraph is difficult to understand.  It seems to 
> be stating
> >that the authenticator can be separated from a AAA client as 
> long as the
> >context of the request is communicated correctly between parties. Is
> >this it?
> 
> I think so. Also, the split would need to be done in such a way that 
> naming ambiguities are not introduced.
> 
[Joe] OK I think this could use some re-wording. I'll try to put some
text together after I get through Bernard's message. 

> Russ
> 

_

Re: Improving Security with Encryption

[Michael . Dillon]

> >I strongly agree and my entire laptop is encrypted.

> If this policy you suggest is taken only a little bit too zealously, 
your 
> company will mandate encrypting your work files,

If your company's goal is to prevent corporate espionage
then this is a rather shortsighted way to do it. If an employee
with such an encrypted laptop is sitting in front of the 
immigration police who ask him for the encryption passwords
then he would be stupid to refuse to divulge it.

A wiser move would be to require all confidential documents
to be encrypted and stored on a server. Before travelling
such documents should be deleted from the laptop. On reaching
the destination, the documents should be retrieved from the
server. This way, if a laptop is lost, stolen, or in the hands
of some police agency in some country or other, there is no
corporate confidential information on it.

And if there is serious risk associated with the confidential
information, whether monetary risk or legal risk associated
with making information public, then this *TRAVEL* rule should
apply to the daily commute as well.

After all, some of you may have noticed this thing called
"the Internet" which makes it easy to move around encrypted
files to any part of the world where a laptop is likely to
travel to.

--Michael Dillon


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Improving Security with Encryption

[Michel Py]

>> Fred Baker wrote:
>> What I would suggest is that people encrypt confidential
>> information on their laptops, and perhaps the entire laptop.

> King, Kimberly S. wrote:
> I strongly agree and my entire laptop is encrypted.

Guys, Jordi was talking about the US government wanting to know what's
in your laptop. If the intel they have on you is that you may carry
information such as how to build a nuke or grow a biological agent, and
if you encrypt the entire thing they're going to confiscate it and
either break the encryption or detain you indefinitely until you cough
up the key.

Keep in mind: you're dealing with the same guys who sent visa renewals
to the terrorists who flew planes in the WTC six months after the entire
world knew they were dead. They won't find more nuke blueprints in your
laptop than they found WMDs in Iraq, but they sure can get annoying
trying.


>> Michel Py wrote:
>> An iPod is a lot more suspicious, IMHO.

> Joe Abley wrote:
> Apparently!
> http://forums.worldofwarcraft.com/thread.html?
> topicId=11211166&pageNo=1&sid=1

And it did not even have one of these Sony batteries that spontaneously
explode :-D
Why build your own bomb to take on the airplane when Apple and Dell
manufacture perfectly good ones, me wonders.

Michel.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

found verizon phone from 339 area code...

[Joel Jaeggli]

please enquire in noc to identify.

joelja

-- 

Joel Jaeggli Unix Consulting  [EMAIL PROTECTED]
GPG Key Fingerprint:   5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Improving Security with Encryption

[Harald Alvestrand]

--On 10. november 2006 10:49 -0600 "James M. Polk" <[EMAIL PROTECTED]> wrote:


At 09:58 AM 11/10/2006 -0500, King, Kimberly S. wrote:

> Fred Baker wrote:
> What I would suggest is that people encrypt confidential
> information on their laptops, and perhaps the entire laptop.

I strongly agree and my entire laptop is encrypted.  Perhaps people could
consider suggesting to their management that data protection is critical
and disk encryption is a simple effective step.


Is *everything* on your laptop work related, or do you (speaking
generally) sneek a few personal files on the laptop.


technology reset:

when you encrypt an entire laptop, that usually means that there's some 
preboot stage that picks up the key from a "secret" place, inserts itself 
as a disk driver, and transparently decrypts everything that comes from the 
disk (and encrypts what goes out).


The encryption doesn't care one whit whether the files are personal, 
work-related or just random gunk off the IETF mailing list.


What it protects against is (I think) people who grab the laptop, pop out 
the disk and try to read it on another device, or without the benefit of 
having cracked the key-hiding code of that particular encryption product.


It doesn't protect you against people who know where the crypt software 
hides the key, but is pretty good against the rest.




   Harald


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: [Ieprep] Re: WG Review: Recharter ofInternet Emergency Preparedness (ieprep)

[Dolly, Martin C, ALABS]

WRT ETS: 
1. Architecture  and service definition/requirements is better fit in
ATIS, with some ITU work.
2. Refinement of requirements for definition of Internet protocols in
the IETF
3. ATIS Standards/Implementation requirements to further ensure
interworking/interoperability

Internet Protocol expertise is clearly here in the IETF, but by the same
token Service and deployed network architecture expertise is where the
service providers "actively" participate, which is ATIS (and where
needed the ITU). 


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Improving Security with Encryption

[Hallam-Baker, Phillip]

Before we get much further into this could I just point out that these issues 
are not unknown?

The content management system built into Windows and Office XP works in this 
exact way. It is based on some well known work done at Xerox Parc.

DRM is not very effective as copyright control as copyright content is 'break 
once run anywhere'. DRM applied to documents is much more effective because you 
do not rely on univerally distributed keys for security.

I don't suggest that the IETF do work in this area as the protocols are 
compromised by multiple conflicting IPR claims that make standards progress 
infeasible even on RAND terms. 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 10, 2006 12:11 PM
> To: ietf@ietf.org
> Subject: Re: Improving Security with Encryption
> 
> > >I strongly agree and my entire laptop is encrypted.
> 
> > If this policy you suggest is taken only a little bit too zealously,
> your 
> > company will mandate encrypting your work files,
> 
> If your company's goal is to prevent corporate espionage then 
> this is a rather shortsighted way to do it. If an employee 
> with such an encrypted laptop is sitting in front of the 
> immigration police who ask him for the encryption passwords 
> then he would be stupid to refuse to divulge it.
> 
> A wiser move would be to require all confidential documents 
> to be encrypted and stored on a server. Before travelling 
> such documents should be deleted from the laptop. On reaching 
> the destination, the documents should be retrieved from the 
> server. This way, if a laptop is lost, stolen, or in the 
> hands of some police agency in some country or other, there 
> is no corporate confidential information on it.
> 
> And if there is serious risk associated with the confidential 
> information, whether monetary risk or legal risk associated 
> with making information public, then this *TRAVEL* rule 
> should apply to the daily commute as well.
> 
> After all, some of you may have noticed this thing called 
> "the Internet" which makes it easy to move around encrypted 
> files to any part of the world where a laptop is likely to travel to.
> 
> --Michael Dillon
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

IETF 67 Network goes down at 12:00

[Jim Martin]

Gentlepeople,
	Consider this the traditional 10am warning that the IETF network  
will go down today at Noon. Alas, we've got a very tight shipping  
schedule today, so we'll have to bring everything down immediately at  
12. The hotel wireless in the lobby of both buildings should be  
available again (for registered guests) on or before noon to provide  
continuing connectivity for folks.


Hope everyone had a good week, and see you all in Prague!

- Jim


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF 67 Network goes down at 12:00

[Brian E Carpenter]

Hope everyone had a good week, and see you all in Prague!


From a network point of view, I think we had an excellent week,
and many thanks to the whole crew!

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Guidance for AAA Key management' to BCP (draft-housley-aaa-key-mgmt)

[Joseph Salowey \(jsalowey\)]

Thanks Bernard,

Comments inline.  

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 08, 2006 2:00 PM
> To: ietf@ietf.org
> Cc: Joseph Salowey (jsalowey)
> Subject: Re: Last Call: 'Guidance for AAA Key management' to 
> BCP (draft-housley-aaa-key-mgmt)
> 
> I believe that the document will have implications for the 
> RADIUS protocol.  For example, during the RADEXT WG meeting 
> at IETF 67, we discussed the need for crypto-agility in 
> RADIUS, and the current lack of ability to negotiate 
> cryptographic algorithms.  This is why Crypto-agility was 
> added as a RADEXT WG work item. 
> 
> Since Diameter already supports cryptographic algorithm 
> negotiation, I do not believe that crypto-agility is an issue there. 
> 
> My reading of the document is that it does not impose any 
> security requirements on EAP methods beyond those described 
> in RFC 4017 and RFC 3748.  At least that is what is being 
> assumed in the EAP Key Management Framework document, which 
> cites RFC 4017 and RFC 3748 as meeting the requirements. 
> 

[Joe] I think it would be helpful to include an appendix on how existing
commonly deployed mechanisms compare against these requirements.  What
do you think?

> I think that the term 'AAA key management' applies to 
> situations which involve use of AAA for derivation or 
> transport of keying material.  In the case of EAP, that would 
> include EAP methods, AAA protocols as well as the SAP.  
> 
> 1. I do think that SAP designers are an audience, 
> particularly since that work often occurs outside of IETF. 
> 
> 2. The AAA protocol does play a role in freshness, because it 
> can support replay protection, preventing the same key 
> transport message from being replayed, thereby introducing 
> stale keys.  
> 
> 3.  I think that "authentication of all parties" is distinct 
> from context binding, although it is certainly a 
> pre-requisite for it.  Without defining the parties to the 
> key management exchange and authenticating them, it is not 
> possible to protect against key usage outside of the 
> authorized scope. 
> 
[Joe] I don't think this is always the case.  Authenticating identity is
different that authorizing scope.  They may depend upon one another, but
do not necessarily have to. 

> 4. Agree that integrity should also be called out. 
> 
> 5. There are vulnerabilities associated with the 802.11i key 
> naming scheme.  For example, I believe that PSK cracking 
> tools have been built that perform offline dictionary attacks 
> on the 802.11i key names.  
> EAP methods satisfying RFC 4017 criteria are not vulnerable, 
> but I do think it illustrates the potential dangers.  The 
> problem is fixed in 802.11r. 
> 
[Joe] OK, how does .11r solve the problem?

> 6. I believe this section applies to binding within all 
> phases, including AAA, EAP and SAP.  Generally AAA integrity 
> protection mechanisms should satisfy the binding requirements 
> (or at least that is what is assumed in the EAP Key 
> Management Framework document).  For EAP, the requirements 
> are met by RFC 4017 requirements (including Channel Binding 
> support).  So in practice the issue has mostly arisen within 
> SAP designs, some of which have not properly handled key 
> scoping and binding.  For example, within IEEE 802.11i, the 
> authenticator is not identified, only the port/BSSID so that 
> the peer cannot properly determine the authenticator key 
> scope.  This is also fixed in 802.11r. 
> 
[Joe] OK, I need to look at .11r.  

> 7.  I think some clarification may be needed here.  As stated 
> in the EAP Key Management Framework document, the 
> authenticator and AAA client are always co-located (though 
> these entities may both be distributed as in some CAPWAP 
> architectures). 
> 
[Joe] OK, this needs clarification. This section also mentions the
keying draft without referencing it. 

> -
> Hi Russ and Bernard,
> 
> I'm not really clear on the purpose of the document.  What 
> does it apply to?  Does it require changes to existing AAA 
> protocols? Does it add new requirements to EAP methods that 
> are not in RFC3748? It would probably be good to reference 
> 3748 when it applies to a requirement in this document (such 
> as replay protection, strong fresh session keys, etc.).
> 
> What does AAA key management protocol refer to?  Is it the 
> combination of EAP, AAA and Security Association Protocol?  
> 
> A few comments on this document
> 
> 1. Section 3 states "This section provides guidance to AAA 
> protocol designers and EAP method designers."
> 
> This should include designers of "security association 
> protocols" as well since many of the requirements apply to them.
> 
> 2. Strong fresh session keys
> 
> In this section it is not clear what the subject session keys 
> are.  It is not clear to me what role the AAA protocol plays 
> in "ensure that the keying materia

Re: [Ieprep] Re: WG Review: Recharter ofInternet Emergency Preparedness (ieprep)

[Scott W Brim]

On 11/09/2006 18:43 PM, Sam Hartman allegedly wrote:
>> "Scott" == Scott W Brim <[EMAIL PROTECTED]> writes:
> 
> Scott> However, it is important that the IETF not *just* do
> Scott> protocols.  The IETF needs to consider how proposed
> Scott> "architectures" fit in with all the other requirements on
> Scott> the Internet.  The IETF doesn't do protocol engineering, it
> Scott> does Internet engineering.  It is fine for other
> Scott> organizations (not necessarily SDOs) to do service
> Scott> requirements and scenarios.  They can *propose*
> Scott> architectures.  If the IETF can support those architectures
> Scott> in ways that are consistent with overall Internet design,
> Scott> then fine.  Otherwise the IETF should not be restricted to
> Scott> just protocol extension/definition.  The IETF has to think
> Scott> of a bigger picture.
> 
> 
> Completely agree.  I'd rather see architectures and systems proposed
> elsewhere, reviewed by the ietf, and then us develop the protocols.
> There may be some cases where we do architecture work; I don't think
> this is one of them.

Please help me figure out the essential differences between
"architecture" that should be done in the IETF and "architecture" that
can be done elsewhere.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: [Ieprep] Re: WG Review: Recharter ofInternet Emergency Preparedness (ieprep)

[Dolly, Martin C, ALABS]

For one, I have yet to see a B2BUA (SBC) in any IETF document. They are
in every service provider network. So, not to reflect them is an
illusion as best. 

-Original Message-
From: Scott W Brim [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 10, 2006 9:31 PM
To: Sam Hartman
Cc: Dolly, Martin C, ALABS; Janet P Gunn; Robert G. Cole; ietf@ietf.org;
ieprep@ietf.org; Scott Bradner; Fred Baker; Pekka Savola
Subject: Re: [Ieprep] Re: WG Review: Recharter ofInternet Emergency
Preparedness (ieprep)

On 11/09/2006 18:43 PM, Sam Hartman allegedly wrote:
>> "Scott" == Scott W Brim <[EMAIL PROTECTED]> writes:
> 
> Scott> However, it is important that the IETF not *just* do
> Scott> protocols.  The IETF needs to consider how proposed
> Scott> "architectures" fit in with all the other requirements on
> Scott> the Internet.  The IETF doesn't do protocol engineering, it
> Scott> does Internet engineering.  It is fine for other
> Scott> organizations (not necessarily SDOs) to do service
> Scott> requirements and scenarios.  They can *propose*
> Scott> architectures.  If the IETF can support those architectures
> Scott> in ways that are consistent with overall Internet design,
> Scott> then fine.  Otherwise the IETF should not be restricted to
> Scott> just protocol extension/definition.  The IETF has to think
> Scott> of a bigger picture.
> 
> 
> Completely agree.  I'd rather see architectures and systems proposed
> elsewhere, reviewed by the ietf, and then us develop the protocols.
> There may be some cases where we do architecture work; I don't think
> this is one of them.

Please help me figure out the essential differences between
"architecture" that should be done in the IETF and "architecture" that
can be done elsewhere.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Improving Security with Encryption

[Russ White]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> A wiser move would be to require all confidential documents
> to be encrypted and stored on a server. Before travelling
> such documents should be deleted from the laptop. On reaching
> the destination, the documents should be retrieved from the
> server. This way, if a laptop is lost, stolen, or in the hands
> of some police agency in some country or other, there is no
> corporate confidential information on it.

I've always believed that the move towards storing tons of stuff on a
laptop is a bad one It risks data in multiple ways. I keep virtually
no data on a laptop, and just count on having network access in some way
to get to it, or I store it on a key I keep encrypted and on/about my
person all the time when traveling, or on an encrypted r/w cd or dvd.

There are so many other ways to transport data than on your laptop's
hard drive that I have a hard time making sense of doing so.

Just my 2c.

:-)

Russ


- --
[EMAIL PROTECTED] CCIE <>< Grace Alone

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

iD8DBQFFVTXCER27sUhU9OQRAr8gAKC6LuHS8YNVW3eJ3AVrUMAVa5yNswCgqOgO
ptwK1LMDRpGKSN3kZrQ9AZw=
=aier
-END PGP SIGNATURE-

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf