What can happen is that a bunch of governments set up their own root servers which no ISP in their right mind will direct their DNS servers at. Nothing will change and the world will continue as it was, except someone gets to look a bit silly.
Someone else will probably point this out, but this year the FCC did in fact approve a band for DECT in the US. Not the same one as in Europe, so the same gear doesn't work and it's ooh.. about 10 years too late.
In Europe, the EEC set aside spectrum (1900Mhz) for the purpose of running DECT. The protocol is neat, it does TDD, pi/4 DQPSK and phones have enough smarts to share the spectrum amongst themselves without interfering.
In the USA, your cordless phones are thrown to the dogs in the unlicensed bands. No predetermined spectrum for the application, so phones have to fight it out at 2.4 and 5Ghz with 802.11, microwave ovens and anything else that uses the band. Better still, since there is no uniform standard for interoperability, your handset will only work with the base it came with and not with another manufacturer's.
DECT in 2.4Ghz (achieved with frequency hopping, so it's not true DECT) does interfere with 802.11. I've done the tests. I've designed both DECT silicon and 802.11 silicon and I can assure you they interfere when they share the same unlicensed band.
You need to prioritize. First worry about your fingers, eyes and arse
1) Get a slick 1600x1200 or better LCD screen 2) Get more screens to broaden your field of view 3) Spend $100+ on a really good keyboard. I choose Happy Hacking. 4) Spend $500+ on a really good office chair (or $5 from a failed startup)
With this as a starting point, you can feel physically comfortable, freeing you to address your mental confort.
The extent to which this matters depends on the type of deployment. For mobile systems it matters a lot, it matters for systems where different parties own each end of the link, it matter when they sell this stuff in comp-usa.
It matters a lot less when the user or service provider owns both ends of the link and can thus verify interoperability ahead of time.
Interoperability labelling does matter in certain scenarios, but compare the timeline of Wimax interop testing against what happened in the Bluetooth Sig or the WiFi Alliance (aka WECA). They are very comparable and consistent with BT and WiFi, it takes time from the initial products coming out to the interop testing to get into full swing.
There is reason to think it's not going to be a worst case scenario. There are a very limited number of silicon vendors. Many products will be based on the same silicon with the same software. This will lead to default profiles pretty quickly.
It is solidly standardized in fixed mode in IEEE 802.16-2004. Products are in the pipeline from a number of manufacturers.
What is at issue is whether service providers will set up in your area. This is a very complex issue where spectrum policy and licensing collide with equipment availability, local permits (for towers etc), the cost of the technology and competition from DSL and cable. I don't pretend to know how it will pan out, but 2006 will be the year that the market gets effectively tested.
The current work is around mobility which relates more to handsets and laptops. This not only in the unfinished 802.16e spec, but in Wimax and the IETF, since for mobility, the backhaul networks need to be standardized and this is outside the realm of the 802.16 working group. Mobility will take some time.
Witty retort, but there's not much comparison between the handful of domestic nutjobs and the veritable flood of unknown persons (including a wide variety of felons and violent gang members) crossing in from Mexico each day.
Yes, yes, I know, they all just come here to work. Right. Which is why our prisons are overflowing with hardworking family men who happen to be illegals.
uh, so you're going to tag all the illegals? I'm sure that'll work real well.
They're not making hydrogen. They're just gathering the stuff that was formed at the start of the universe (or created by God if you're a dumb creationist).
If its bit strength on the link cipher you're worried about then define a stronger link cipher. If it's the authentication method then define a new EAP method.
802.11i is extensible like that. It it only the base modes for interoperability that are mandated. Support for vendor proprietary additions are included and are distinguised using the standard IEEE OUI.
WAPI throws the whole lot out (they delete clause 8 and start over) and replaces it with something broken.
WAPI is insecure, doesn't scale, late and undeployable.
If you read the specs and had any involvement in the 802.11i process, you will understand what an amature piece of work WAPI is. It was compounded with the blatant IP grab that China was trying to make with WAPI (you have to send China your RTL, they *THEY* can integrate it into your chip - yeah right).
The only way you can effectively write 802.11 specifications for anything as intertwined with the base spec is to go to the 802 meetings and propose your scheme. From 802, down through 802.11 and the 802.11 task groups, the documents are heavily cross dependent and part of the purpose of these massive meetings is to make sure that all the bits fit together and are kept up to date with respect to each other.
Trying to write an 802.11i replacement in isolation is doomed to failure and fail is exactly what they did.
Now they are forum shopping. ISO rubber stamps the 802 documents because 802 has a long history of succesful open standards development. Whining 'it's not fair! They won't take our spec but they will take the IEEE specs' is disingenuous bullshit and they know it. There is a basic quality threshold you have to pass first.
Mutual authentication sounds safe and warm. Alice know Bob is at the other end Bob knows Alice is at the other end.
However this is the situation after you have performed the mutual authentication, not before. In all protocols I have seen, this takes place in some order. In order for Alice to authenticate Bob's identity and the other way around, with both exchanges bound together (so differentiating from bilateral authentication), Either Alice or Bob has to first reveal their identity so it can be authenticated. This includes the proposed scheme.
This asks the question "Who goes first". Usually the protocol forces this issue and leaves one side or the other in the disavantageous position of identifying themselves first. This is analagous to the gatekeeper shouting "Halt! Who goes there?" to someone trying to enter. The person trying to enter is forced to go first and reveal themselves.
I may not want to reveal my identity to anyone, especially when it comes to say, wandering around in public with a wireless device. All sorts of tracking mechanisms become possible.
What we want is a "Who goes first protocol" so I can enforce my own policy on revealing my identity. If someone wants to sell to me, they had better go first. If I'm trying to get through a door, the building owner can reasonably expect me to go first. There are plenty of situations where a network may want to only reveal its identity to people who are allowed to know its identity, and noone else.
We already have the algorithms, but the protocols are stuck in the mud and prevent us from moving forward with security that offers more than what SSL gives us.
What the world does not need is another generalized mutual authentication method. These are used to place a veneer of security on a generally insecure thing.
E.G. Credit card transactions over the internet. These are protected by SSL/TLS. This is somewhat removed from the credit card transaction itself, instead protecting the link rather than the transaction. So you log onto vendorX's web site and use certs with SSL/TLS to protect the link. You feel conforted by the little lock icon in the corner of your screen and proceed to hand VendorX all the details needed to drain arbitary amounts of money from your credit card.
Instead.. Protect the transaction directly, with something like a secure credit card transaction protocol. VendorX doesn't need your credit card details, he needs your money. The security protocols should run between you and the vendor to establish a transaction and the vendor's identity, between you and your credit card company to authorize a payment against the transaction to VendorX and between the credit card company and VendorX to transfer the payment.
VendorX gets the money, not a blank, signed cheque.
Repeat exercise for all activities you need to secure, applying appropriate measures for the situation. Leave SSL/TLS for securing the link, not the application.
Mutual authentication is nothing new. There exist many mutual authentication schemes that are resistant to man in the middle attacks and also ensure liveness of the exchanges.
The one described here looks to be a simple shared secret method. In may situations, certificate based methods are used in order to avoid the need to securely distribute a shared secret ahead of time.
For a shared secret based mutual auth, why not do the normal thing and pass random numbers and their hashes back and forth, mixed in with the challenge-response sequences needed to establish an authenticated identity, a shared session secret and liveness? Read various EAP drafts or 802.11i or recent 802.16e drafts for real world examples of how to do this. The details necessarily change with the context.
These methods have the benefit of lots of analysis by the crypto community. This delayed password disclosure scheme doesn't seem to have the same benefit.
No. However the infrastructure across the UK is ancient and so neglected since Thatcher put the knife in that it pretty much needs completely replacing.
Rather than installing a *lot* of cabling, a wireless system would obviously be cheaper.
We started out with a limited number of names for things. Planets, stars, the sun. They we found some more things like comets and asteroids.
Now we've found lots of things that come in between, requiring a different form of classification. The only problem is that people are trying to squeeze the definition of things we know about into a limited naming set.
To name something doesn't mean we understand it and being unable to name something doesn't mean we don't understand it.
People should stop worrying and be happy that we can describe these objects to a higher level of detail than can be described using the existing names we had for things floating in space.
>Two and a half inches long, dark green/brown and stained with a little blood on the end, it was close to the consistency of a pencil eraser in parts, moving to the consistency of jello at one end.
>This survey has come out at least once a year for as long as I can remember. "US kids lack in X discipline." Next up: US childhood obesity is the rise.
That's because the situation is real, hasn't changed and they measure it every year.
Slashdot Mirror
What can happen is that a bunch of governments set up their own root servers which no ISP in their right mind will direct their DNS servers at. Nothing will change and the world will continue as it was, except someone gets to look a bit silly.
Someone else will probably point this out, but this year the FCC did in fact approve a band for DECT in the US. Not the same one as in Europe, so the same gear doesn't work and it's ooh.. about 10 years too late.
DECT is and area where the FCC has let you down.
In Europe, the EEC set aside spectrum (1900Mhz) for the purpose of running DECT. The protocol is neat, it does TDD, pi/4 DQPSK and phones have enough smarts to share the spectrum amongst themselves without interfering.
In the USA, your cordless phones are thrown to the dogs in the unlicensed bands. No predetermined spectrum for the application, so phones have to fight it out at 2.4 and 5Ghz with 802.11, microwave ovens and anything else that uses the band. Better still, since there is no uniform standard for interoperability, your handset will only work with the base it came with and not with another manufacturer's.
DECT in 2.4Ghz (achieved with frequency hopping, so it's not true DECT) does interfere with 802.11. I've done the tests. I've designed both DECT silicon and 802.11 silicon and I can assure you they interfere when they share the same unlicensed band.
You need to prioritize. First worry about your fingers, eyes and arse
1) Get a slick 1600x1200 or better LCD screen
2) Get more screens to broaden your field of view
3) Spend $100+ on a really good keyboard. I choose Happy Hacking.
4) Spend $500+ on a really good office chair (or $5 from a failed startup)
With this as a starting point, you can feel physically comfortable, freeing you to address your mental confort.
The extent to which this matters depends on the type of deployment. For mobile systems it matters a lot, it matters for systems where different parties own each end of the link, it matter when they sell this stuff in comp-usa.
It matters a lot less when the user or service provider owns both ends of the link and can thus verify interoperability ahead of time.
Interoperability labelling does matter in certain scenarios, but compare the timeline of Wimax interop testing against what happened in the Bluetooth Sig or the WiFi Alliance (aka WECA). They are very comparable and consistent with BT and WiFi, it takes time from the initial products coming out to the interop testing to get into full swing.
There is reason to think it's not going to be a worst case scenario. There are a very limited number of silicon vendors. Many products will be based on the same silicon with the same software. This will lead to default profiles pretty quickly.
It is solidly standardized in fixed mode in IEEE 802.16-2004. Products are in the pipeline from a number of manufacturers.
What is at issue is whether service providers will set up in your area. This is a very complex issue where spectrum policy and licensing collide with equipment availability, local permits (for towers etc), the cost of the technology and competition from DSL and cable. I don't pretend to know how it will pan out, but 2006 will be the year that the market gets effectively tested.
The current work is around mobility which relates more to handsets and laptops. This not only in the unfinished 802.16e spec, but in Wimax and the IETF, since for mobility, the backhaul networks need to be standardized and this is outside the realm of the 802.16 working group. Mobility will take some time.
Witty retort, but there's not much comparison between the handful of domestic nutjobs and the veritable flood of unknown persons (including a wide variety of felons and violent gang members) crossing in from Mexico each day.
Yes, yes, I know, they all just come here to work. Right. Which is why our prisons are overflowing with hardworking family men who happen to be illegals.
uh, so you're going to tag all the illegals? I'm sure that'll work real well.
They're not making hydrogen. They're just gathering the stuff that was formed at the start of the universe (or created by God if you're a dumb creationist).
Ugh.
1) No decrypt specified. So it doesn't work with many modes.
2) Complete ambiguity in the endianess of the test vectors. Which end is which?
3) Optimized for HW complexity. We have AES for that. We want new ciphers optimized for security.
Time will tell. Right now I need a haircut.
Do you think his hair is transparent to IR, or the IR made his hair fall out?
So the time and place to fix this would have been around 2 years ago in the IEEE 802.11i meetings.
If its bit strength on the link cipher you're worried about then define a stronger link cipher. If it's the authentication method then define a new EAP method.
802.11i is extensible like that. It it only the base modes for interoperability that are mandated. Support for vendor proprietary additions are included and are distinguised using the standard IEEE OUI.
WAPI throws the whole lot out (they delete clause 8 and start over) and replaces it with something broken.
AES, CCM and TKIP is free of royalties. I don't think the same can be said of WAPI, even if you could make it work.
Repeat after me... WAPI is Crappy.
WAPI is insecure, doesn't scale, late and undeployable.
If you read the specs and had any involvement in the 802.11i process, you will understand what an amature piece of work WAPI is. It was compounded with the blatant IP grab that China was trying to make with WAPI (you have to send China your RTL, they *THEY* can integrate it into your chip - yeah right).
The only way you can effectively write 802.11 specifications for anything as intertwined with the base spec is to go to the 802 meetings and propose your scheme. From 802, down through 802.11 and the 802.11 task groups, the documents are heavily cross dependent and part of the purpose of these massive meetings is to make sure that all the bits fit together and are kept up to date with respect to each other.
Trying to write an 802.11i replacement in isolation is doomed to failure and fail is exactly what they did.
Now they are forum shopping. ISO rubber stamps the 802 documents because 802 has a long history of succesful open standards development. Whining 'it's not fair! They won't take our spec but they will take the IEEE specs' is disingenuous bullshit and they know it. There is a basic quality threshold you have to pass first.
Mutual authentication sounds safe and warm. Alice know Bob is at the other end Bob knows Alice is at the other end.
However this is the situation after you have performed the mutual authentication, not before. In all protocols I have seen, this takes place in some order. In order for Alice to authenticate Bob's identity and the other way around, with both exchanges bound together (so differentiating from bilateral authentication), Either Alice or Bob has to first reveal their identity so it can be authenticated. This includes the proposed scheme.
This asks the question "Who goes first". Usually the protocol forces this issue and leaves one side or the other in the disavantageous position of identifying themselves first. This is analagous to the gatekeeper shouting "Halt! Who goes there?" to someone trying to enter. The person trying to enter is forced to go first and reveal themselves.
I may not want to reveal my identity to anyone, especially when it comes to say, wandering around in public with a wireless device. All sorts of tracking mechanisms become possible.
What we want is a "Who goes first protocol" so I can enforce my own policy on revealing my identity. If someone wants to sell to me, they had better go first. If I'm trying to get through a door, the building owner can reasonably expect me to go first. There are plenty of situations where a network may want to only reveal its identity to people who are allowed to know its identity, and noone else.
We already have the algorithms, but the protocols are stuck in the mud and prevent us from moving forward with security that offers more than what SSL gives us.
What the world does not need is another generalized mutual authentication method. These are used to place a veneer of security on a generally insecure thing.
E.G. Credit card transactions over the internet. These are protected by SSL/TLS. This is somewhat removed from the credit card transaction itself, instead protecting the link rather than the transaction. So you log onto vendorX's web site and use certs with SSL/TLS to protect the link. You feel conforted by the little lock icon in the corner of your screen and proceed to hand VendorX all the details needed to drain arbitary amounts of money from your credit card.
Instead.. Protect the transaction directly, with something like a secure credit card transaction protocol. VendorX doesn't need your credit card details, he needs your money. The security protocols should run between you and the vendor to establish a transaction and the vendor's identity, between you and your credit card company to authorize a payment against the transaction to VendorX and between the credit card company and VendorX to transfer the payment.
VendorX gets the money, not a blank, signed cheque.
Repeat exercise for all activities you need to secure, applying appropriate measures for the situation. Leave SSL/TLS for securing the link, not the application.
Mutual authentication is nothing new. There exist many mutual authentication schemes that are resistant to man in the middle attacks and also ensure liveness of the exchanges.
The one described here looks to be a simple shared secret method. In may situations, certificate based methods are used in order to avoid the need to securely distribute a shared secret ahead of time.
For a shared secret based mutual auth, why not do the normal thing and pass random numbers and their hashes back and forth, mixed in with the challenge-response sequences needed to establish an authenticated identity, a shared session secret and liveness? Read various EAP drafts or 802.11i or recent 802.16e drafts for real world examples of how to do this. The details necessarily change with the context.
These methods have the benefit of lots of analysis by the crypto community. This delayed password disclosure scheme doesn't seem to have the same benefit.
Just fit one of these above the antenna. You can fake any journey or lack thereof that you choose.
No. However the infrastructure across the UK is ancient and so neglected since Thatcher put the knife in that it pretty much needs completely replacing.
Rather than installing a *lot* of cabling, a wireless system would obviously be cheaper.
They are doing it because its cheaper.
This joke did the rounds during the first US-Iraq war and shortly after a big train accident..
What is the difference between British Rail and a Scud missile?
British Rail kills people.
We started out with a limited number of names for things. Planets, stars, the sun. They we found some more things like comets and asteroids.
Now we've found lots of things that come in between, requiring a different form of classification. The only problem is that people are trying to squeeze the definition of things we know about into a limited naming set.
To name something doesn't mean we understand it and being unable to name something doesn't mean we don't understand it.
People should stop worrying and be happy that we can describe these objects to a higher level of detail than can be described using the existing names we had for things floating in space.
I have Charles Babbage's ego in a box somewhere. Should be worth a bit.
>Two and a half inches long, dark green/brown and stained with a little blood on the end, it was close to the consistency of a pencil eraser in parts, moving to the consistency of jello at one end.
Will you be auctioning it on Ebay?
>This survey has come out at least once a year for as long as I can remember. "US kids lack in X discipline." Next up: US childhood obesity is the rise.
That's because the situation is real, hasn't changed and they measure it every year.