<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments for Sean Convery</title>
	<link>http://www.seanconvery.com/weblog</link>
	<description>Ruminations on Identity Management for Networks</description>
	<pubDate>Sat, 17 May 2008 02:51:14 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>Comment on DHCP, 802.1X, and the Default VLAN by Pedro Alipio</title>
		<link>http://www.seanconvery.com/weblog/2006/08/02/dhcp-8021x-and-the-default-vlan/#comment-46885</link>
		<dc:creator>Pedro Alipio</dc:creator>
		<pubDate>Wed, 14 May 2008 10:31:02 +0000</pubDate>
		<guid>http://www.seanconvery.com/weblog/2006/08/02/dhcp-8021x-and-the-default-vlan/#comment-46885</guid>
		<description>In my point of view, the best solution for this issue should be the authentication server sending an DHCP FORCERENEW message (RFC3203) whenever an user logs in (802.1x). Unfortunately, RFC3203 is not supported by most of the DHCP servers and clients.</description>
		<content:encoded><![CDATA[<p>In my point of view, the best solution for this issue should be the authentication server sending an DHCP FORCERENEW message (RFC3203) whenever an user logs in (802.1x). Unfortunately, RFC3203 is not supported by most of the DHCP servers and clients.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Coding Humans Into Your Security Apps by totesport casino bonus code</title>
		<link>http://www.seanconvery.com/weblog/2005/11/07/coding-humans-into-your-security-apps/#comment-46884</link>
		<dc:creator>totesport casino bonus code</dc:creator>
		<pubDate>Mon, 12 May 2008 04:17:00 +0000</pubDate>
		<guid>http://www.seanconvery.com/weblog/2005/11/07/coding-humans-into-your-security-apps/#comment-46884</guid>
		<description>&lt;strong&gt;totesport casino bonus code...&lt;/strong&gt;

crescent shaping blemish!numerous Marriott ...</description>
		<content:encoded><![CDATA[<p><strong>totesport casino bonus code&#8230;</strong></p>
<p>crescent shaping blemish!numerous Marriott &#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on DHCP, 802.1X, and the Default VLAN by Sean</title>
		<link>http://www.seanconvery.com/weblog/2006/08/02/dhcp-8021x-and-the-default-vlan/#comment-46881</link>
		<dc:creator>Sean</dc:creator>
		<pubDate>Fri, 09 May 2008 21:16:28 +0000</pubDate>
		<guid>http://www.seanconvery.com/weblog/2006/08/02/dhcp-8021x-and-the-default-vlan/#comment-46881</guid>
		<description>S.

Can you be more specific when you say "the client unauthenticates"? Are they issuing an EAP-Logoff? Is the machine rebooted? Is link interrupted on the switch? Also, what supplicant and OS are you using?

Thanks,

Sean</description>
		<content:encoded><![CDATA[<p>S.</p>
<p>Can you be more specific when you say &#8220;the client unauthenticates&#8221;? Are they issuing an EAP-Logoff? Is the machine rebooted? Is link interrupted on the switch? Also, what supplicant and OS are you using?</p>
<p>Thanks,</p>
<p>Sean</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on DHCP, 802.1X, and the Default VLAN by S. Yrneh</title>
		<link>http://www.seanconvery.com/weblog/2006/08/02/dhcp-8021x-and-the-default-vlan/#comment-46878</link>
		<dc:creator>S. Yrneh</dc:creator>
		<pubDate>Fri, 09 May 2008 00:39:45 +0000</pubDate>
		<guid>http://www.seanconvery.com/weblog/2006/08/02/dhcp-8021x-and-the-default-vlan/#comment-46878</guid>
		<description>A problem im facing while implementing 802.1x........ with guest vlan feature. 
A client connects to a 802.1x enabled port, and guest vlan is configured so it gets a IP address in the guest vlan. Then the client gets authenticated and move to the access vlan and since the port state changed the client will get a new IP address in the access vlan. However, if the client unauthenticates come back to the guest vlan, even though port state changed again the client does not release/renew its IP address.

Anyone got any work around for this ?</description>
		<content:encoded><![CDATA[<p>A problem im facing while implementing 802.1x&#8230;&#8230;.. with guest vlan feature.<br />
A client connects to a 802.1x enabled port, and guest vlan is configured so it gets a IP address in the guest vlan. Then the client gets authenticated and move to the access vlan and since the port state changed the client will get a new IP address in the access vlan. However, if the client unauthenticates come back to the guest vlan, even though port state changed again the client does not release/renew its IP address.</p>
<p>Anyone got any work around for this ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on IPv6 And Security Architecture Changes by Sean</title>
		<link>http://www.seanconvery.com/weblog/2008/03/31/ipv6-and-security-architecture-changes/#comment-46873</link>
		<dc:creator>Sean</dc:creator>
		<pubDate>Tue, 29 Apr 2008 21:30:36 +0000</pubDate>
		<guid>http://www.seanconvery.com/weblog/2008/03/31/ipv6-and-security-architecture-changes/#comment-46873</guid>
		<description>Hi Ed,

I think the biggest initial deployment challenge will quite simply be inexperience with the technology. There is very little understanding of IPv6 in the networking community, let alone IPv6 security considerations.

I do agree that there will be implementation flaws and we're probably only beginning to detect them. In the meantime, dual-stack systems with IPv4 and IPv6 running concurrently represent a very interesting attack vector as you can use a potentially insecure IPv6 stack to get onto the IPv4 network. In my testing back in 2004 there were instances of personal firewalls only protecting the IPv4 portion of the connectivity and leaving the IPv6 portion completely wide open.

Fuzzing IPv6 stacks will certainly yield some flaws, not sure if anyone's done anything comprehensive yet.</description>
		<content:encoded><![CDATA[<p>Hi Ed,</p>
<p>I think the biggest initial deployment challenge will quite simply be inexperience with the technology. There is very little understanding of IPv6 in the networking community, let alone IPv6 security considerations.</p>
<p>I do agree that there will be implementation flaws and we&#8217;re probably only beginning to detect them. In the meantime, dual-stack systems with IPv4 and IPv6 running concurrently represent a very interesting attack vector as you can use a potentially insecure IPv6 stack to get onto the IPv4 network. In my testing back in 2004 there were instances of personal firewalls only protecting the IPv4 portion of the connectivity and leaving the IPv6 portion completely wide open.</p>
<p>Fuzzing IPv6 stacks will certainly yield some flaws, not sure if anyone&#8217;s done anything comprehensive yet.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on IPv6 And Security Architecture Changes by Edward Vielmetti</title>
		<link>http://www.seanconvery.com/weblog/2008/03/31/ipv6-and-security-architecture-changes/#comment-46872</link>
		<dc:creator>Edward Vielmetti</dc:creator>
		<pubDate>Tue, 29 Apr 2008 15:07:04 +0000</pubDate>
		<guid>http://www.seanconvery.com/weblog/2008/03/31/ipv6-and-security-architecture-changes/#comment-46872</guid>
		<description>Sean -

Do you think that the biggest initial deployment security issues in IPv6 will revolve around implementation correctness, and the ability to test for same?

What comes to mind quickly is things like IPv6 fuzzing a la

http://seclists.org/pen-test/2008/Apr/0136.html

which calls for the need for systematic ways to test correctness without knowing a priori what parts of the system are likely to break first.</description>
		<content:encoded><![CDATA[<p>Sean -</p>
<p>Do you think that the biggest initial deployment security issues in IPv6 will revolve around implementation correctness, and the ability to test for same?</p>
<p>What comes to mind quickly is things like IPv6 fuzzing a la</p>
<p><a href="http://seclists.org/pen-test/2008/Apr/0136.html" rel="nofollow">http://seclists.org/pen-test/2008/Apr/0136.html</a></p>
<p>which calls for the need for systematic ways to test correctness without knowing a priori what parts of the system are likely to break first.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on DHCP, 802.1X, and the Default VLAN by David Hyson</title>
		<link>http://www.seanconvery.com/weblog/2006/08/02/dhcp-8021x-and-the-default-vlan/#comment-46870</link>
		<dc:creator>David Hyson</dc:creator>
		<pubDate>Fri, 25 Apr 2008 14:46:14 +0000</pubDate>
		<guid>http://www.seanconvery.com/weblog/2006/08/02/dhcp-8021x-and-the-default-vlan/#comment-46870</guid>
		<description>We're running wired 802.1x on our campus with Enterasys equipment, and seem to have many of the same kind of issues.  It sounds like in your implementation authorized supplicants don't go through a default VLAN.  In our, they do, and it's caused quite a few issues.   In particular,  Netlogon was starting while the machine was still in "purgatory" and consequently getting a bad connection to the domain and not loading a mandatory profile.  Even turning off XP fast-startup option didn't fix it.  I actually wrote a service that we now use here that delays the start of Netlogon until a machine gets a non-default IP.  It helps quite a bit, but I think we're going to try shortening the lease as well.  Thanks for the insight.  -DLH</description>
		<content:encoded><![CDATA[<p>We&#8217;re running wired 802.1x on our campus with Enterasys equipment, and seem to have many of the same kind of issues.  It sounds like in your implementation authorized supplicants don&#8217;t go through a default VLAN.  In our, they do, and it&#8217;s caused quite a few issues.   In particular,  Netlogon was starting while the machine was still in &#8220;purgatory&#8221; and consequently getting a bad connection to the domain and not loading a mandatory profile.  Even turning off XP fast-startup option didn&#8217;t fix it.  I actually wrote a service that we now use here that delays the start of Netlogon until a machine gets a non-default IP.  It helps quite a bit, but I think we&#8217;re going to try shortening the lease as well.  Thanks for the insight.  -DLH</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Is Wi-Fi Secure? Sabres at Ten Paces by casino en internet</title>
		<link>http://www.seanconvery.com/weblog/2005/11/04/is-wi-fi-secure-sabres-at-ten-paces/#comment-46867</link>
		<dc:creator>casino en internet</dc:creator>
		<pubDate>Tue, 22 Apr 2008 10:52:59 +0000</pubDate>
		<guid>http://www.seanconvery.com/weblog/2005/11/04/is-wi-fi-secure-sabres-at-ten-paces/#comment-46867</guid>
		<description>&lt;strong&gt;casino en internet...&lt;/strong&gt;

misunderstandings loneliest rails....</description>
		<content:encoded><![CDATA[<p><strong>casino en internet&#8230;</strong></p>
<p>misunderstandings loneliest rails&#8230;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on OpenSEA Adds HP and Aruba, Ships 2.0.0 by Paul Walsh</title>
		<link>http://www.seanconvery.com/weblog/2007/12/18/opensea-adds-hp-and-aruba-ships-200/#comment-41014</link>
		<dc:creator>Paul Walsh</dc:creator>
		<pubDate>Wed, 13 Feb 2008 02:36:25 +0000</pubDate>
		<guid>http://www.seanconvery.com/weblog/2007/12/18/opensea-adds-hp-and-aruba-ships-200/#comment-41014</guid>
		<description>Jennifer,
Is Kevin Porter thr product manager in the USA or the UK or in Ireland?</description>
		<content:encoded><![CDATA[<p>Jennifer,<br />
Is Kevin Porter thr product manager in the USA or the UK or in Ireland?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Inference-based Identity by Sean Convery &#187; Blog Archive &#187; Schneier&#8217;s Wide-Open Wireless Argument</title>
		<link>http://www.seanconvery.com/weblog/2006/08/10/inference-based-identity/#comment-36293</link>
		<dc:creator>Sean Convery &#187; Blog Archive &#187; Schneier&#8217;s Wide-Open Wireless Argument</dc:creator>
		<pubDate>Thu, 17 Jan 2008 01:17:41 +0000</pubDate>
		<guid>http://www.seanconvery.com/weblog/2006/08/10/inference-based-identity/#comment-36293</guid>
		<description>[...] Second, Schneier seems to think that the risks to him are as follows: someone breaks into his machine or someone does something illegal using his network. There is a significant third risk he doesn&#8217;t cover: the increased risk of identity theft / profiling. Watching the Internet use and search habits of a machine is very easy over an open wireless network. Watching that use over a long period of time could be very revealing (and profitable, just ask Google). What I find borderline hilarious is that the blogosphere proponents of open networks are the vary same folks that rightly went a bit bonkers when AOL released the search data of 650,000 users. This data was partially anonymized by removing the screen name of the searcher but as the New York Times and others reported, it is fairly trivial to analyze searches and derive identity. I wrote about how the same techniques might apply to enterprise Identity. What I find funny is while the damage done is at least self-inflicted in the open wireless case, the repercussions could be even more disastrous. With a persistent log of not just your searches but your internet traffic in total over a period of time, it would be very easy to tell an awful lot about you. If you think the bad guys need to be parked out front to do this, you haven&#8217;t spent enough time looking at snack-food wireless antennas. [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Second, Schneier seems to think that the risks to him are as follows: someone breaks into his machine or someone does something illegal using his network. There is a significant third risk he doesn&#8217;t cover: the increased risk of identity theft / profiling. Watching the Internet use and search habits of a machine is very easy over an open wireless network. Watching that use over a long period of time could be very revealing (and profitable, just ask Google). What I find borderline hilarious is that the blogosphere proponents of open networks are the vary same folks that rightly went a bit bonkers when AOL released the search data of 650,000 users. This data was partially anonymized by removing the screen name of the searcher but as the New York Times and others reported, it is fairly trivial to analyze searches and derive identity. I wrote about how the same techniques might apply to enterprise Identity. What I find funny is while the damage done is at least self-inflicted in the open wireless case, the repercussions could be even more disastrous. With a persistent log of not just your searches but your internet traffic in total over a period of time, it would be very easy to tell an awful lot about you. If you think the bad guys need to be parked out front to do this, you haven&#8217;t spent enough time looking at snack-food wireless antennas. [&#8230;]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
