RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Sam Hartman wrote: One of the things coming out of the most recent BOF was a strong desire for PA-level interoperability. That can be accomplished through standardized attributes or vendor-specific attributes that are sufficiently well documented (and not subject to patents) that third parties can implement collectors or analysis tools that interoperate with the vendor tools for the vendor attributes. Will we be able to meet these interoperability goals? Why or why not? Yes, we can. If we define a small set of standardized attributes (OS and app version, AV status, etc.) and make them mandatory to implement, then we will have interoperability with respect to those attributes. We should allow the definition of attributes that go beyond this minimal standard mandatory to implement (MTI) set but the MTI set will provide a baseline of information available for all endpoints that implement NEA. Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Narayanan, Vidya wrote: Harald, This seems to be missing the point. I think there is a general sense that NEA could be helpful for some level of protection to complying endpoints in an enterprise scenario, which is exactly what you have described below. The disagreement seems to be on the topics of what NEA does for the network and whether it makes any sense in the provider model where the network and end device owners are different. I'm not sure who is missing what point at this time note that the term network does NOT mean ISP network. People who use it as if it means that contribute to confusion. Also, the term network has been used both in the meaning of layer 3 network and in the meaning of the set of interconnected devices that make up the computing environment of an enterprise. On the network protection issue, I still have not seen anything that NEA provides that is not provided (in a better manner) by protection mechanisms that the network must use to protect itself against any unknown vulnerabilities and compromised endpoints. Everything that has been said still seems to be a subset of that larger threat which must be protected against anyway. Having said that, the use of NEA for the provider model doesn't make sense, since providers are interested in protecting their networks more than protecting the devices they don't own. Not to mention that they cannot really hope to get compliance from devices they don't own. Noting the scenarios above, I claim that NEA-like functionality has proved useful already in protecting the computing environment of an enterprise. I have not seen compelling evidence that it has any use in the layer 3 infrastructure used to carry customer traffic at an ISP. But I think that's beside the point - the use cases for which we know that NEA may be useful are already compelling enough that we should stop debating whether or not to charter the group and get on with the work. My opinion. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Vidya Narayanan wrote: I am very apprehensive of achieving any meaningful PA-level interoperability. I am not sure what minimum set of PA attributes will be standardized, but, whatever that set is, I doubt will be sufficient to provide any acceptable level of security, even for the endpoints. This is not surprising, since you have said that you don't see any security value to NEA. Even assuming ongoing standardization of vendor specific attributes, it is not totally realistic to assume that all applications will support the appropriate attributes. The rate of standardization is also very likely to be much slower than the rate of the growth in the number of attributes needed for any continued meaningful protection. NEA is not based on applications supporting attributes. Attributes are supported by Posture Collectors and Posture Validators, specialized NEA components. An AV Posture Collector will handle attributes pertaining to AV, perhaps by interfacing with an existing AV application. Still, I agree that a given endpoint will typically only support a small subset of the universe of possible attributes. Not a problem. As long as the endpoint supports enough attributes that the Posture Broker can evaluate its compliance with the posture policy, that's enough. Thanks, Steve -Original Message- From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] Sent: Monday, October 16, 2006 5:06 PM To: Sam Hartman; Frank Yeh Jr Cc: Hardie, Ted; [EMAIL PROTECTED]; ietf@ietf.org Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Sam, -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 12:43 PM To: Frank Yeh Jr Cc: Hardie, Ted; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Frank == Frank Yeh [EMAIL PROTECTED] writes: Frank Standardized VS vendor-specific attributes is not something that needs to be Frank solved today. Solutions can start with vendor-specific and migrate toward a Frank standard, if one develops, without changing the protocol. The specification Frank should not preclude the addition of standardized attributes. IE the Frank specification is like an alphabet, attributes are like vocabulary. You can add Frank new words without changing the letters. One of the things coming out of the most recent BOF was a strong desire for PA-level interoperability. That can be accomplished through standardized attributes or vendor-specific attributes that are sufficiently well documented (and not subject to patents) that third parties can implement collectors or analysis tools that interoperate with the vendor tools for the vendor attributes. Will we be able to meet these interoperability goals? Why or why not? I am very apprehensive of achieving any meaningful PA-level interoperability. I am not sure what minimum set of PA attributes will be standardized, but, whatever that set is, I doubt will be sufficient to provide any acceptable level of security, even for the endpoints. Even assuming ongoing standardization of vendor specific attributes, it is not totally realistic to assume that all applications will support the appropriate attributes. The rate of standardization is also very likely to be much slower than the rate of the growth in the number of attributes needed for any continued meaningful protection. Regards, Vidya ___ Nea mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/nea ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
At 11:06 PM 10/16/2006, Harald Alvestrand wrote: Narayanan, Vidya wrote: Harald, snip Noting the scenarios above, I claim that NEA-like functionality has proved useful already in protecting the computing environment of an enterprise. I have not seen compelling evidence that it has any use in the layer 3 infrastructure used to carry customer traffic at an ISP. But I think that's beside the point - the use cases for which we know that NEA may be useful are already compelling enough that we should stop debating whether or not to charter the group and get on with the work. It seems that there are a number of people believing that NEA might be useful in Enterprise networks where the network and the endpoints attaching to the network are owned and controlled by the same entity. I know your words are proved useful; but perhaps we might agree that it's an arms race, so to speak. Note that the notion of proved useful is unlike the type of guarantees we are used to in the Security area. The charter currently says in part There is an open issue with respect to NEA applicability in deployment scenarios where the endpoint is owned by a party that is different from the organization providing network access. That is ambiguous. I suggested adding the following applicability statement before: NEA is applicable to networks where endpoints accessing the network are owned and tightly controlled by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. That also seems ambiguous as per the recent discussions, so I propose the following revision, based on your words Harald: NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. Let us make that change so it is clear to everyone as to what NEA might and might not do. Lakshminath My opinion. Harald ___ 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: [Nea] WG Review: Network Endpoint Assessment (nea)
At 12:00 AM 10/17/2006, Khosravi, Hormuzd M wrote: Sam, I believe if we move 'quickly' in this WG we will be able to meet interoperability goals to certain extent atleast. The bottom-line is this technology is already being deployed by different vendors in academia and enterprises. The question is should IETF get involved in standardizing this or leave it to the individual vendors. I believe the IETF should and that standardization will certainly help the community, if we can move fast enough. Whereas interoperability is a noble goal, the IETF also has the good habit of clearly specifying what our protocols do and don't do. Our bar is thankfully higher than marketing literature for example. The recent email by Jari Arkko to standardize some of the EAP methods which are being used and deployed today but no RFCs exist for them, is certainly a step in the right direction. Good example actually: 3748 contains brutal truths about some of the legacy EAP methods, for instance on MD5-Challenge -- which no one should really be using for access control -- it says: Auth. mechanism: Password or pre-shared key. Ciphersuite negotiation: No Mutual authentication: No Integrity protection: No Replay protection: No Confidentiality: No Key derivation:No Key strength: N/A Dictionary attack prot.: No Fast reconnect:No Crypt. binding:N/A Session independence: N/A Fragmentation: No Channel binding: No In other words, someone who uses that protocol gets zilch! Now of course, in the real world, a variant of this protocol was used and soon after publicly demonstrated to be useless. best regards, Lakshminath My 2 cents, Hormuzd ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Lakshminath Dondeti wrote: At 11:06 PM 10/16/2006, Harald Alvestrand wrote: Narayanan, Vidya wrote: Harald, snip Noting the scenarios above, I claim that NEA-like functionality has proved useful already in protecting the computing environment of an enterprise. I have not seen compelling evidence that it has any use in the layer 3 infrastructure used to carry customer traffic at an ISP. But I think that's beside the point - the use cases for which we know that NEA may be useful are already compelling enough that we should stop debating whether or not to charter the group and get on with the work. It seems that there are a number of people believing that NEA might be useful in Enterprise networks where the network and the endpoints attaching to the network are owned and controlled by the same entity. I know your words are proved useful; but perhaps we might agree that it's an arms race, so to speak. Note that the notion of proved useful is unlike the type of guarantees we are used to in the Security area. The charter currently says in part There is an open issue with respect to NEA applicability in deployment scenarios where the endpoint is owned by a party that is different from the organization providing network access. That is ambiguous. I suggested adding the following applicability statement before: NEA is applicable to networks where endpoints accessing the network are owned and tightly controlled by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. That also seems ambiguous as per the recent discussions, so I propose the following revision, based on your words Harald: NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. Let us make that change so it is clear to everyone as to what NEA might and might not do. I don't think we have any proof that this statement is true. I can think of scenarios where NEA would be useful, but they depend on various circumstances that either would be very specialized or require a great deal of faith in order to believe they would happen. I suggest: All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
At 12:29 AM 10/17/2006, Harald Alvestrand wrote: Lakshminath Dondeti wrote: At 11:06 PM 10/16/2006, Harald Alvestrand wrote: Narayanan, Vidya wrote: Harald, snip snip NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. Let us make that change so it is clear to everyone as to what NEA might and might not do. I don't think we have any proof that this statement is true. I can think of scenarios where NEA would be useful, but they depend on various circumstances that either would be very specialized or require a great deal of faith in order to believe they would happen. I suggest: All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. Ok. For the benefit of the editor: Let us replace: There is an open issue with respect to NEA applicability in deployment scenarios where the endpoint is owned by a party that is different from the organization providing network access. with NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Extensible Provisioning Protocol (EPP)' to DraftStandard (draft-hollenbeck-epp-rfc3730bis)
-Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 1:33 PM To: ietf@ietf.org Subject: Re: Last Call: 'Extensible Provisioning Protocol (EPP)' to DraftStandard (draft-hollenbeck-epp-rfc3730bis) Hi. RFC 3967 is not applicable in cases where the appropriate solution is to advance the normative downreference on the standards track. In each case where you have a normative down reference, to a PS, please explain why advancing that document is not the appropriate solution. It is my opinion that it would be hard to do so is not a reasonable answer to this question. Your note wasn't addressed to me, Sam, but I will assume that you're asking me the question. Since some of the reference RFCs are cited in multiple documents it'll be more efficient to address them individually. In all cases but one it's not the protocol that's being cited normatively, but a portion of the referenced specification. Advancing the referenced documents probably *is* the theoretically appropriate solution. The apparent lack of interest or inability to do so is the practical problem. Rather than being stalled indefinitely, I think I can remove or revise the normative references as follows: RFC 3023 (XML Media Types) Referenced by: draft-hollenbeck-epp-rfc3730bis-03 3023 is referenced only in the media registration template provided in appendix B. A case could be made that this reference is thus informative. RFC 3339 (Date and Time on the Internet: Timestamps) Referenced by: draft-hollenbeck-epp-rfc3730bis-03, draft-hollenbeck-epp-rfc3731bis-04, draft-hollenbeck-epp-rfc3732bis-03, draft-hollenbeck-epp-rfc3733bis-04 This reference is sited to capture a format that is also available in the W3C's XML Schema specifications. It can be replaced with an existing normative reference to the W3C specification. RFC 3513 (Internet Protocol Version 6 (IPv6) Addressing Architecture) Referenced by: draft-hollenbeck-epp-rfc3732bis-03 This reference is cited only to capture IPv6 address syntax. 3513 has been obsoleted by 4291, which is a draft standard. The reference to 3513 could be replaced with a reference to 4291. RFC 2822 (Internet Message Format) Referenced by: draft-hollenbeck-epp-rfc3733bis-04 This reference is cited only to capture SMTP email address syntax. It can be replaced with RFC 822, which is a full standard. RFC 2246 (The TLS Protocol Version 1.0) Referenced by: draft-hollenbeck-epp-rfc3734bis-03 This is probably a problem because rfc3734bis does indeed require an implementation of TLS. 2246 has been obsoleted by 4346 (TLS 1.1), which is itself a Proposed Standard. The TLS working group is currently working on 4346bis (TLS 1.2); the intent is to produce another Proposed Standard. Perhaps rfc3734bis could be recycled at Proposed until 4346bis or a successor progresses or our standards track processes change to deal with the situation some other way. The other possibility is to consider this text from 3967: There are exceptional procedural or legal reasons that force the target of the normative reference to be an informational or historical RFC or to be at a lower standards level than the referring document. with a specific focus on the exceptional procedural words. The TLS working group (established in 1996) charter doesn't currently include a plan to advance any version of the specification to Draft Standard status. I've been following the TLS work and I understand the need for revisions to deal with vulnerabilities, but the lack of a Draft Standard version of TLS puts all work that depends on TLS in standards track purgatory. Is that an exceptional procedural reason? -Scott- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Network Endpoint Assessment (nea)
Ted, As I understand your concerns expressed below, you are concerned that standardizing attributes for NEA would be redundant and pointless: redundant because vendor-specific attributes will cover the same information in more detail and pointless because remediation will not be possible given the limited information available through the standardized attributes. Is that right? If so, maybe it would help to explain why we want to have standardized attributes. The goal is to ensure that any NEA endpoint and server can interoperate in a meaningful manner without making the assumption that endpoint and server have the same vendor plug-ins installed. For this to be true, we must ensure that every NEA endpoint provides a basic set of information to the NEA server. That basic set of information will be the standardized attributes. If the endpoint and server both understand vendor-specific attributes that provide more information, that's great. But we want to ensure a base level of interoperability. Yes, remediation may be difficult using only the information in the standardized attributes. But a captive portal technique can be used to provide information to the endpoint user about how to remediate. Thanks, Steve Ted Hardie wrote: I have a very basic fear that this working group is getting chartered with a bunch of aims added by people who will not take on the task of doing the work. After private discussion with folks involved, my sense is that the very core of this work is a perceived need to be able to pass opaque strings between a host and the network prior to the host attaching. Those opaque strings are, essentially, the vendor-specific strings currently associated with posture assessment. The standard protocol carrying these strings would connect on the network side to a system that has plug-ins which understand the vendor-specific strings. With a charter that clarified that this was intended to assist the end systems with vulnerabilities prior to attachment because the network they are attaching to might be filled with danger, I think this work would get done reasonably quickly. (As a control mechanism to protect the network, I agree with the point made clearly by others that this is not appropriate). I am less sure of the task of standardizing attributes. I am not sure that the number of attributes which can be standardized will ever be high enough to be truly useful, and I am pretty sure that all of these will be already covered by vendor-specific attributes. Since there must be an assessor in place on the client for those few standardized attributes to be assessed and that assessor will likely already have these covered by vendor-specific attributes, in other words, we seem to be standardizing redundancy. On the network attachment side, it is possible, of course, that an offer of remediation could be made based on just the standard attributes, but it seems far more likely that it would be a two step process (assess standard attributes, then pass vendor-specific attributes to vendor plug-in). Again, if the vendor's attributes cover the standard attributes, then this is largely redundant and may add measurable latency; it seems far more likely that step one would simply be skipped if there were a vendor-specific string and an available plug-in. Since there has to be an assessor, the first seems very likely to me. If you don't have a vendor's plug-in, then I suppose there is some chance that you will trust and act based on the standard attributes, but the chance of getting the right remediation seems pretty slight in those circumstances. Especially when many vulnerabilities are a combination of conditions, (Browser version Foo on OS patch level Bar) that you could remediate by upgrading either one, checking for and acting on the attributes which could be standardized seems of very, very limited utility. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Extensible Provisioning Protocol (EPP)' to DraftStandard (draft-hollenbeck-epp-rfc3730bis)
Hollenbeck, == Hollenbeck, Scott [EMAIL PROTECTED] writes: -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 1:33 PM To: ietf@ietf.org Subject: Re: Last Call: 'Extensible Provisioning Protocol (EPP)' to DraftStandard (draft-hollenbeck-epp-rfc3730bis) Hollenbeck, RFC 2246 (The TLS Protocol Version 1.0) Referenced Hollenbeck, by: draft-hollenbeck-epp-rfc3734bis-03 This is Hollenbeck, probably a problem because rfc3734bis does indeed Hollenbeck, require an implementation of TLS. 2246 has been Hollenbeck, obsoleted by 4346 (TLS 1.1), which is itself a Hollenbeck, Proposed Standard. The TLS working group is Hollenbeck, currently working on 4346bis (TLS 1.2); the intent is Hollenbeck, to produce another Proposed Standard. Perhaps Hollenbeck, rfc3734bis could be recycled at Proposed until Hollenbeck, 4346bis or a successor progresses or our standards Hollenbeck, track processes change to deal with the situation Hollenbeck, some other way. The other possibility is to consider Hollenbeck, this text from 3967: Hollenbeck, There are exceptional procedural or legal reasons Hollenbeck, that force the target of the normative reference to Hollenbeck, be an informational or historical RFC or to be at a Hollenbeck, lower standards level than the referring document. Hollenbeck, with a specific focus on the exceptional procedural Hollenbeck, words. If we have IETf consensus that we consider this sort of procedural reason sufficient, then I support the exception. I also support such an IETf consensus. I think that would be a significant change in how we approach draft standards. While I don't mind using your document as a test case,I do think it important that your document not be unusual in this regard. If we approve this sort of exception we should plan to approve exceptions whenever similar situations arise. If we're going to do that we should update RFC 3967 to be more clear. So, let's see if we have consensus on your document set . If so, let's go publish your documents. Then I can try to recruit someone to make minor updates to 3967. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-kolkman-appeal-support
Michael == Michael Thomas [EMAIL PROTECTED] writes: Michael John C Klensin wrote: (1) The supporter procedure/requirement should be triggered only is someone shows symptoms of being a vexatious appellant. People who are entering their first appeals don't trigger it. People whose last appeal was successful, even in part (that would need to be defined, of course, and that might not be easy) don't trigger it. The only folks who need to look for supporters are those who have appealed before and whose appeals have been rejected as without merit. Michael Can an appeal be rejected with merit? Yes. I think Robert's recent appeal was rejected that way. I personally think that Jefsey's appeal against the LTRU registry doc set was a reasonable appeal although we declined to make any changes. I suspect many people may disagree with me and argue that this appeal was without merit. I think the SPF and Sender ID appeals clearly had merit. I'm not sure whether we rejected them though. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-kolkman-appeal-support
Sam, et al, I doubt that noting an appeal has been determined to have merit is especially useful. As Sam implies below, it is possible to have controversy over this point, and any controversy is likely to mean no annotation of merit will occur in many cases. Ignoring for the moment the potential for recursion (do we need to have supporters for the merit of an appeal after the fact?), it seems to me that it might be more useful to treat any appeal for which there was not an absolute consensus that no merit could be ascribed to the appeal, as an appeal with merit. -- Eric -- -Original Message- -- From: Sam Hartman [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, October 17, 2006 11:11 AM -- To: Michael Thomas -- Cc: John C Klensin; Ned Freed; ietf@ietf.org; Eliot Lear -- Subject: Re: draft-kolkman-appeal-support -- -- Michael == Michael Thomas [EMAIL PROTECTED] writes: -- -- Michael John C Klensin wrote: -- (1) The supporter procedure/requirement should be triggered -- only is someone shows symptoms of being a vexatious -- appellant. -- People who are entering their first appeals don't trigger it. -- People whose last appeal was successful, even in part (that -- would need to be defined, of course, and that might not be -- easy) don't trigger it. The only folks who need to look for -- supporters are those who have appealed before and -- whose appeals -- have been rejected as without merit. -- -- -- -- Michael Can an appeal be rejected with merit? -- -- Yes. I think Robert's recent appeal was rejected that way. I -- personally think that Jefsey's appeal against the LTRU registry doc -- set was a reasonable appeal although we declined to make -- any changes. -- I suspect many people may disagree with me and argue that -- this appeal -- was without merit. -- -- I think the SPF and Sender ID appeals clearly had merit. -- I'm not sure -- whether we rejected them though. -- -- -- ___ -- 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: draft-kolkman-appeal-support
Gray, Eric wrote: Sam, et al, I doubt that noting an appeal has been determined to have merit is especially useful. As Sam implies below, it is possible to have controversy over this point, and any controversy is likely to mean no annotation of merit will occur in many cases. Ignoring for the moment the potential for recursion (do we need to have supporters for the merit of an appeal after the fact?), it seems to me that it might be more useful to treat any appeal for which there was not an absolute consensus that no merit could be ascribed to the appeal, as an appeal with merit. The reason I asked is because this is in the context of a (d)dos attack on the appeals process. Some people are clearly more litigious than others, but if the appeal at least has merit that seems a lot more acceptable than those who keep bringing up baseless junk. Maybe we need an IESG work duty program for problem appealers. No more appeals until you've done X amount of community duty. I guess that requiring that they wear orange jumpsuites might be a little over the top. Mike -- Eric -- -Original Message- -- From: Sam Hartman [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, October 17, 2006 11:11 AM -- To: Michael Thomas -- Cc: John C Klensin; Ned Freed; ietf@ietf.org; Eliot Lear -- Subject: Re: draft-kolkman-appeal-support -- -- Michael == Michael Thomas [EMAIL PROTECTED] writes: -- -- Michael John C Klensin wrote: -- (1) The supporter procedure/requirement should be triggered -- only is someone shows symptoms of being a vexatious -- appellant. -- People who are entering their first appeals don't trigger it. -- People whose last appeal was successful, even in part (that -- would need to be defined, of course, and that might not be -- easy) don't trigger it. The only folks who need to look for -- supporters are those who have appealed before and -- whose appeals -- have been rejected as without merit. -- -- -- -- Michael Can an appeal be rejected with merit? -- -- Yes. I think Robert's recent appeal was rejected that way. I -- personally think that Jefsey's appeal against the LTRU registry doc -- set was a reasonable appeal although we declined to make -- any changes. -- I suspect many people may disagree with me and argue that -- this appeal -- was without merit. -- -- I think the SPF and Sender ID appeals clearly had merit. -- I'm not sure -- whether we rejected them though. -- -- -- ___ -- 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: draft-kolkman-appeal-support
--On Tuesday, 17 October, 2006 11:10 -0400 Sam Hartman [EMAIL PROTECTED] wrote: Michael Can an appeal be rejected with merit? Yes. I think Robert's recent appeal was rejected that way. I personally think that Jefsey's appeal against the LTRU registry doc set was a reasonable appeal although we declined to make any changes. I suspect many people may disagree with me and argue that this appeal was without merit. I think the SPF and Sender ID appeals clearly had merit. I'm not sure whether we rejected them though. Sam, For me, the bottom-line question in each of those cases is either: (1) Whether you think the IETF and its program and processes were injured or improved by the questions being raised on appeal, and (2) Whether you think the appellants intent was negative enough, relative to general IETF functioning, that you think measures should be taken to discourage them from filing further appeals or to make it more difficult for them to do so. You pick which question you like. To me, they are essentially equivalent. And, to me, unless the answer to the chosen question is yes, then Olaf's proposal, as written, either adds bureaucracy without accomplishing anything or, worse, discourages the filing of appeals that are actually beneficial to the community --in terms of the discussion they cause if not in changing a particular decision. If without merit doesn't describe the condition I'm looking for well, then let's work on devising a different term and test. And, if deciding which appeals are vexatious and which ones are ok is too burdensome --especially relative to hearing a few more appeals-- then, IMO, we shouldn't be spending time on trying to figure out ways to make appeals harder. To me, discouraging behavior we want (and, IMO, need) to encourage in order to make things a little bit more difficult for a few bad guys is a fairly poor tradeoff. If we had a lot of bad guy-induced problems that were paralyzing us and no other ideas, then it might be worth it. But, if we don't have that level of obviously bad behavior, we should be considering options that focus on the behavior we consider unacceptable, not on making things more difficult for everyone. I guess that, if we could figure out a way to do it, that would make me a supporter of Mike's suggestions -- either the community service version or the orange jumpsuit one. Of course, as suggested in earlier notes, I'd find the idea of endorsements (supporters) completely acceptable and even a good idea (i) if anyone in who participates actively in the IETF could do an endorsement, (ii) if there were no restriction on repeat endorsements, (iii) if the endorsements were expected to contain analysis and information that actually contributed to the consideration of the appeal, and (iv) if the whole endorsement idea had been sufficient thought through that we could have confidence that requests for endorsements did not set off discussions firestorms on the IETF list. I haven't seen that proposal yet, and, for me, trying to design it falls under the moratorium on process work I'm trying to enforce on myself. regards, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
At 2:04 AM -0400 10/17/06, Stephen Hanna wrote: Will we be able to meet these interoperability goals? Why or why not? Yes, we can. If we define a small set of standardized attributes (OS and app version, AV status, etc.) and make them mandatory to implement, Sorry, but doesn't AV status above refer to the existing, proprietary anti-virus systems? How does standardizing an attribute for carrying that help create a standardized understanding of what it means?Don't I still have to treat that as, essentially, a vendor attribute, since I have to know which vendor statuses cover which vulnerabilities? Or do you mean there is some anti-virus software here? Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-kolkman-appeal-support
John == John C Klensin [EMAIL PROTECTED] writes: John And, if deciding which appeals are vexatious and which ones John are ok is too burdensome --especially relative to hearing a John few more appeals-- then, IMO, we shouldn't be spending time John on trying to figure out ways to make appeals harder. I agree with you. I think for several recent IESg appeals, there would be unanimous support on the IESG for the proposition that considering the appeal did not help the IETF or its processes. In cases like that, it seems like having a fast track to get rid of appeals is beneficial. The main question in my mind is what mechanism we use to prevent the appealed body from abusing this mechanism. I don't think fast track mechanisms are needed for appeals to WG chairs or ADs. If the appeal is without merit, it takes the AD very little time to write up a brief note denying the appeal. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Ted, Sorry, but doesn't AV status above refer to the existing, proprietary anti-virus systems? How does standardizing an attribute for carrying that help create a standardized understanding of what it means?Don't I still have to treat that as, essentially, a vendor attribute, since I have to know which vendor statuses cover which vulnerabilities? Or do you mean there is some anti-virus software here? I would think that five or six values are appropriate: 1. Vendor name (string) 2. Vendor engine version (integer) 3. Vendor virus definitions version (integer) 4. Enabled? (binary) 5. Buggered? (binary) 6. Other gobbledigook the vendor wants to include that might get standardized later. (blob) I could envision 3 being a bit of an issue if it is possible to update specific viruses but not others. I would expect the normal enterprise administrator to be able to act on the first 5. The 6th is there as a placeholder. I'm not sure I'd trust 5 if it's false. I'd also suggest we're well into solving the problem at this point. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
At 8:22 PM +0200 10/17/06, Eliot Lear wrote: would think that five or six values are appropriate: 1. Vendor name (string) 2. Vendor engine version (integer) 3. Vendor virus definitions version (integer) 4. Enabled? (binary) 5. Buggered? (binary) 6. Other gobbledigook the vendor wants to include that might get standardized later. (blob) I could envision 3 being a bit of an issue if it is possible to update specific viruses but not others. Thanks for this. I was assuming we were talking primarily about a 1 and 3 combined value. As it stands now, you need access to the vendor's database to know what viruses are covered by any specific version (your 3). For the charter discussions, I want to know whether it will be an aim of the working group to standardize: * a way of carrying this information * the structure of this information (but not its content) * a standard representation of the content, so that access to the vendor database is no longer required The tasks are substantially different in scope, and the level of interoperabilty the community can expect from them are similarly different. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
On Oct 17, 2006, at 11:22 AM, Eliot Lear wrote: I would think that five or six values are appropriate: 1. Vendor name (string) 2. Vendor engine version (integer) 3. Vendor virus definitions version (integer) 4. Enabled? (binary) 5. Buggered? (binary) 6. Other gobbledigook the vendor wants to include that might get standardized later. (blob) This still seems like too much. Information offered for access can be contained within one or more certificates. The information within these certificates should be limited to a minimal set of values: 1) creator 2) class 3) user-host 4) time-stamp 5) update resources The essential information would be the creator/class/user-host/time- stamp fields. When protection is not enabled or is buggered, then a newer certificate should not be offered. The virus definitions or patch updates can be deduced from the time-stamp or by extensions added to class, i.e. AVX-VISTA-37. If a vulnerability is reported subsequent to the time-stamp regarding the creator/class of service, then a new certificate could be required. This would simplify tracking at the access point. By keeping the information exchanged and decisions limited to this minimal information, NEA should provide a valuable services in many environments. Perhaps there should be some consideration given regarding which sets of certificates are offered in various environments. Allowing the certificates to be accessed beyond an authentication process seems to increase security exposures. As this information is not trustworthy, there would be also little gained sharing this information elsewhere. In fact, sharing this information may increase infection rates when this aids malware. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
legal issue of RFC3619
Hi, We are implementing an Ethernet protection ring. Then we found there is an information RFC3619. It is submitted by Extreme network and its IPR is protected by the company too. We also found there are some patents filed by Extreme. In addition to EAPS, we also found there is MRP from Foundry, EPSR from Allied Telesyn, ERP from Siemens. They are all like the same. Isn't it legal violation? We tried to contact Extreme before. But there is no concrete response on the licensing process. Any comment is welcome. Thanks. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Extensible Provisioning Protocol (EPP)' to DraftStandard (draft-hollenbeck-epp-rfc3730bis)
Hollenbeck, Scott wrote: RFC 3339 (Date and Time on the Internet: Timestamps) Referenced by: draft-hollenbeck-epp-rfc3730bis-03, draft-hollenbeck-epp-rfc3731bis-04, draft-hollenbeck-epp-rfc3732bis-03, draft-hollenbeck-epp-rfc3733bis-04 This reference is sited to capture a format that is also available in the W3C's XML Schema specifications. It can be replaced with an existing normative reference to the W3C specification. That's odd, why should you be forced to replace a normative reference to the perfectly fine RFC 3339 by some spec. published elsewhere ? AFAIK nothing is wrong with RFC 3339, let's just promote it if that's what it takes to reference it. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-kolkman-appeal-support
Sam Hartman wrote: I think the SPF and Sender ID appeals clearly had merit. One decision said we have found merit, and the other said we thank... I'm not sure whether we rejected them though. ...the latter was in essence accepted, and the former also had some effect, together resulting in the longest IESG note I've seen anywhere so far. The IAB decided that conflicting IETF experiments are allowed if there's an appropriate IESG disclaimer. A kind of kids, don't try this at home maybe. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: legal issue of RFC3619
Bill, The IETF stays strictly out of such discussions. It is entirely up to each implementor to decide whether or not the claimed IPR is valid and to make arrangements with the IPR owners if so. Please see RFC 3979 for more details, and see https://datatracker.ietf.org/public/ipr_disclosure.cgi for all current disclosures to the IETF. Sorry but this is something your company has to resolve for itself. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter IETF Chair Bill Su wrote: Hi, We are implementing an Ethernet protection ring. Then we found there is an information RFC3619. It is submitted by Extreme network and its IPR is protected by the company too. We also found there are some patents filed by Extreme. In addition to EAPS, we also found there is MRP from Foundry, EPSR from Allied Telesyn, ERP from Siemens. They are all like the same. Isn't it legal violation? We tried to contact Extreme before. But there is no concrete response on the licensing process. Any comment is welcome. Thanks. ___ 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
Protocol Action: ' Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation' to Proposed Standard
The IESG has approved the following document: - 'Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation ' draft-ietf-rddp-sctp-07.txt as a Proposed Standard This document is the product of the Remote Direct Data Placement Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-sctp-07.txt Technical Summary This document describes a method to adapt Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) to Stream Control Transmission Protocol (SCTP) RFC2960 using a generic description found in the RDMA and DDP specifications. This adaption provides a method for two peers to know that each side is performing DDP or RDMA thus enabling hardware acceleration if available. Some implementations may include this adaptation layer within their SCTP implementations to obtain maximum performance but the behavior of SCTP will be unaffected. In order to accomplish this we specify the use of the new adaptation layer indication as defined in the SCTP ADDIP specification. Working Group Summary In contrast to the lengthy discussion of how to adapt rddp to TCP, there has been very little controversy over or dissent from this draft's approach for adapting rddp to SCTP. Protocol Quality The protocol has been reviewed for the rddp WG by David L. Black. Randy Stewart, an SCTP expert, is a co-author of this draft. David Black ([EMAIL PROTECTED]) has acted as PROTO Document Shepherd. Eric Gray ([EMAIL PROTECTED]) has reviewed this document for Gen-ART. Lars Eggert ([EMAIL PROTECTED] has reviewed this document for the IESG. RFC Editor Note OLD: The DDP Segment Chunk serves the same purpose as the [I-D.ietf-rddp-mpa] Upper Layer NEW: The DDP Segment Chunk serves the same purpose as the MPA [I-D.ietf-rddp-mpa] Upper Layer ^^^ Add the following paragraph to the end of Section 13 Security Considerations: Additional requirements apply to security for RDDP over SCTP, due to the use of SCTP as the transport protocol. An implementation of IPsec for RDDP over SCTP: a) MUST support IPsec functionality for SCTP equivalent to the IPsec functionality for TCP that is required by RFC 3723, b) SHOULD support the same level of IPsec functionality for SCTP and TCP unless there is no support for TCP, and c) MUST support at least the level of protocol and port selector functionality for SCTP that is supported for TCP. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Administration of the IANA Special Purpose Address Block' to Informational RFC
The IESG has approved the following document: - 'Administration of the IANA Special Purpose Address Block ' draft-huston-ipv6-iana-specials-01.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-huston-ipv6-iana-specials-01.txt Technical Summary This document represents a direction to IANA concerning the management of the IANA Special Purpose IPv6 address assignment registry. Working Group Summary The document is an individual submission. It was produced by the IAB IPv6 ad hoc committee in an attempt to get through a piece of IPv6 allocation policies where a IETF standardization activity (Teredo) required an IPv6 address allocation, but the RIR allocation policies for IPv6 did not encompass such an action, and IANA did not have a clear and unambiguous authority to perform a direct allocation that was not via the RIRs. This document was produced as a part of the set of IAB considerations that was intended to provide a documented path to allow IANA to perform this allocation as a direct allocation and to provide a documented means of satisfying any future similar requests, so that each time a standards action requires a 'special use IPv6 address it does not become another exception action. Protocol Quality The document went through IETF Last Call and was reviewed by Dan Romascanu on behalf of the IESG and Juergen Schoenwaelder on behalf of the security directorate. The closely interested parties, the IAB, IANA and the RIRs, were consulted in order to ensure that what is being proposed in this draft is the appropriate course of action from the perspective of all parties. The result is a carefully worded document that allows the IETF to produce standard specification that includes 'special use' address allocations, and empower IANA to undertake corresponding allocations from the IP address pool under the authority of IETF standards actions without upsetting the existing arrangements that exist between IANA, ICANN and the RIRs for conventional address allocation functions (and policies) that are outside the direct purview of the IETF. Note to RFC Editor 1. Please make the following change in the title of the document: OLD: Administration of the IANA Special Purpose Address Block NEW: Administration of the IANA Special Purpose IPv6 Address Block 2. Please adjust the boilerplate text to conform with the current IETF default text. 3. Please make the following changes in Section 3: OLD: Further assignments of address space to IANA for subsequent designation of address prefixes for the purposes listed here shall be undertaken only in response to direction to IANA provided by the IETF in a IESG-reviewed RFC document. NEW: Following the policies outlined in [RFC2434], further assignments of address space to IANA for subsequent designation of address prefixes for the purposes listed here shall be undertaken through an IETF Consensus action. OLD: The IANA may undertake IPv6 address designations in support of special purposes as requested in IANA Considerations sections in IESG-reviewed RFCs, where a unicast address is requested with an intended use of the designated address block for the purpose of testing or experimental usage activities initiated by IETF, or for specialised use of the address block within an anycast use context associated with an Internet Standards track protocol. NEW: The IANA may undertake IPv6 address designations in support of special purposes as requested in IANA Considerations sections in IESG-reviewed RFCs, where an address is requested with an intended use of the designated address block for the purpose of testing or experimental usage activities initiated by IETF, or for specialised use of the address block in a context (e.g., anycast) associated with an Internet Standards track protocol. OLD: 5. The nature of the purpose of the designated address (unicast experiment or protocol service anycast). 6. If the purpose is an experimental unicast application, as distinct from an anycast service address, then the registry will also identify the entity and related contact details to whom the address designation has been made. NEW: 5. The nature of the purpose of the designated address (e.g., unicast experiment or protocol service anycast). 6. For experimental unicast applications and otherwise as appropriate, the registry will also identify the entity and related contact details to whom the address designation has been made. 4. Please add the following Informative Reference: [RFC2434] Narten, T., and H. ALvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, RFC2434, October 1998. 5. Please add at the numbered
Protocol Action: 'Internet Application Protocol Collation Registry' to Proposed Standard
The IESG has approved the following document: - 'Internet Application Protocol Collation Registry ' draft-newman-i18n-comparator-14.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-14.txt Technical Summary Many Internet application protocols include string-based lookup, searching, or sorting operations. However the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function and the repertoire of comparison functions can be extended in the future. This document is a normative reference for several standards-track specifications. Working Group Summary This document is the work of individual submitters, but encouraged by multiple working groups. It was reviewed by members of the IMAPEXT and SIEVE working groups and members of the [EMAIL PROTECTED] mailing list. Last call comments were received and addressed. Protocol Quality Scott Hollenbeck and Lisa Dusseault reviewed this specification for the IESG. Note to RFC Editor Section 3.1: please fix an ABNF rule and add a paragraph after it: OLD: collation-scope = Language-tag / vnd- reg-name NEW: collation-scope = Language-tag / vnd- reg-name Note: the ABNF production Language-tag is imported from Language Tags [5] and reg-name from URI: Generic Syntax [9]. Section 3.1: please remove the unused ABNF rule for vendor-tag. OLD: vendor-tag = vnd- hostname Section 5.2, OLD: In this way, collations can be used with protocols that are defined such that |x is a substring of y returns true-false. NEW: In this way, collations can be used with protocols that are defined such that x is a substring of y returns true-false. Section 6: Please add one sentence at the beginning. NEW: This section is informative. Section 6, OLD: In IMAP, the default collation is i;ascii-casemap, because its operations are understood to match's IMAP's built-in operations. NEW: In IMAP, the default collation is i;ascii-casemap, because its operations are understood to match IMAP's built-in operations. Section 9, OLD: Compatibility with widely deployed code was judged more important than Some of the perhaps surprising aspects of these collations are necessary to maintain compatibility with widely deployed code. NEW: Compatibility with widely deployed code was judged more important than fixing the collations. Some of the perhaps surprising aspects of these collations are necessary to maintain compatibility with widely deployed code. Normative References, please add: NEW: [9] Duerst, M. and M. Suignard, âInternationalized Resource Identifiers (IRIs)â, RFC 3987, January 2005. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Quick-Start for TCP and IP' to Experimental RFC
The IESG has approved the following document: - 'Quick-Start for TCP and IP ' draft-ietf-tsvwg-quickstart-07.txt as an Experimental RFC This document is the product of the Transport Area Working Group Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-quickstart-07.txt Technical Summary This document defines an optional means of accelerating normal slow start(ish) transfer rate procedures of a transport protocol into the (potentially many) Mbps flows have access to. The Quickstart sending rate is requested, and never mandatory. The fall back is to normal slow start(ish) ramp ups, requiring many RTTs, in bandwidth utilized. This document outlines how Quickstart is used in TCP, but the mechanism is not specific to any transport protocol - with a lot of discussion on how it affects UDP (VoIP) flows. This document limits flows that can use Quickstart to at least 80kbps or higher. There are pitfalls and problems to be explored with this mechanism (most thought of are discussed extensively), which is why this is Experimental, instead of Standards Track. Rough running code of this mechanism already exists in several places, with generally positive results, even for VoIP. Working Group Summary There is strong consensus in the WG to publish this document. It has been reviewed by several people in the WG last call. Comments raised have been addressed. Protocol Quality This document is making an experimental, optional extension to transport protocol initial transfer rates. TCP is highlighted in the document, though other transport protocols are able to use this mechanism. It is not making a new protocol. This document has been well reviewed in the WG and comments raised have been addressed promptly. James Polk ([EMAIL PROTECTED]) has acted as Document Shepherd. Lars Eggert ([EMAIL PROTECTED]) has reviewed this document for the IESG. Note to RFC Editor Add the following text as the first item in Section 9.2: The cost of having a Quick-Start request packet dropped: Measurement studies cited earlier [MAF04] suggest that on a wide range of paths in the Internet, TCP SYN packets containing unknown IP options will be dropped. Thus, for the sender one risk in using Quick-Start is that the packet carrying the Quick-Start Request could be dropped in the network. It is particularly costly to the sender when a TCP SYN packet is dropped, because in this case the sender should wait for an RTO of three seconds before re-sending the SYN packet, as specified in Section 4.7.2. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
UPDATED: WG Review: Handover Keying (hokey)
A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following UPDATED draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 23rd. +++ Handover Keying (hokey) == Current Status: Proposed Working Group Chair(s): TBD Security Area Director(s): Russ Housley [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] Security Area Advisor: Russ Housley [EMAIL PROTECTED] Mailing List: [EMAIL PROTECTED] Most deployments of EAP in wireless networks employ an authenticator in pass-through mode, usually located at the edge, coupled with a backend AAA/EAP server. Many EAP methods generate an MSK and an EMSK. The MSK is used by several EAP lower layers. The EMSK remains at the peer and server, but it is not presently used in any specifications. Different EAP lower layers make use of the MSK differently; the most common usage is to derive Transient Session Keys (TSKs) to provide access link security in networks (e.g., IEEE 802.11i, IEEE 802.16e), although some lower layers (e.g., IKEv2) use the MSK for other purposes. Extensions to current EAP key framework will be needed to facilitate inter-authenticator handover and roaming. Some problems that need to be addressed with extensions to EAP keying include: 1) Inter-authenticator handovers require re-execution of EAP authentication even though the same EAP authentication server is used. Handover scenarios vary considerably in their fundamental assumptions. In scenarios where hosts remain connected during the handover period, EAP authentication need not be in the critical path for handover. However, there are scenarios where necessary connectivity is not available to support make before break communications. In these scenarios, significant handover latency can result. To avoid this latency, SDOs have employed methods such as context transfer and anchoring that are inefficient or insecure or both. 2) EAP peers with unexpired keying material from a full EAP exchange must take part in a full EAP exchange with the same AAA server to extend a session. While some EAP methods provide fast re-authentication mechanisms, a consistent, EAP-method-independent, low-latency re-authentication mechanism is needed. 3) EAP generates keys (MSK and EMSK). When the EAP WG updated the protocol and specified the keying framework, many details regarding the use of the EMSK were not specified. The EMSK can be used as the root of a cryptographic key hierarchy, and then the keys in the hierarchy are used in various ways to provide the needed security services. In order to ensure that different keys derived from the EMSK are cryptographically separate and that the key derivations are coordinated in an acceptable manner, it is important to clearly specify the top of the topology for the key hierarchy and some guidelines for child key derivations. 4) When wireless networks employ AAA infrastructures, the cross-domain roaming is handled by inter-domain authentication via the home AAA/EAP server. Any authentication must pass through the home server, which increases latency. Latency can be reduced by establishing a trust relationship between the EAP peer and the visited domain's AAA/EAP server. This trust relationship would be brokered by the home EAP/AAA server. Efficient re-authentication for the EAP peer can be supported locally within the visited domain. Some of the inconsistency in current handoff and roaming solutions can be attributed to different trade-offs between computational cost, mobility performance, and security. Specifications are not consistent in the way that the key derivation function (KDF) and KDF parameters are used. Clear direction by the IETF on the topology and construction of a key hierarchy could reduce some of the inconsistencies. However, the HOKEY WG will not attempt to standardize TSK derivation from the MSK, as this would interference with work of other SDOs. The solutions specified by the HOKEY WG fall into several categories, based on timing and mechanism. The authentication and key management may occur before handoff, when latency is much less critical. Alternatively, authentication and key management can occur as part of the handoff, where latency is critical. Solutions should reduce or eliminate the number of referrals to AAA servers, and solutions should avoid re-executing lengthy EAP method exchanges. This may be accomplished by providing new mechanisms for cryptographic keying material in combination with a protocol for the timely delivery of appropriate keys to the appropriate entities. Solutions are expected to include handover keying, low-latency re-authentication, and pre-authentication. All solution categories are useful, each supporting different scenarios. The HOKEY WG may provide multiple solutions, each
WG Review: Recharter of Host Identity Protocol (hip)
A modified charter has been submitted for the Host Identity Protocol (hip) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 23rd. +++ Host Identity Protocol (hip) Current Status: Active Working Group Chair(s): David Ward [EMAIL PROTECTED] Gonzalo Camarillo [EMAIL PROTECTED] Internet Area Director(s): Jari Arkko [EMAIL PROTECTED] Mark Townsley [EMAIL PROTECTED] Internet Area Advisor: Mark Townsley [EMAIL PROTECTED] Mailing Lists: General Discussion: [EMAIL PROTECTED] To Subscribe: http://www1.ietf.org/mailman/listinfo/hipsec Archive: http://www.ietf.org/mail-archive/web/hipsec/index.html Description of Working Group: The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys. The public keys are typically, but not necessarily, self generated. There are five publicly known interoperating HIP implementations, some of which are open source. Currently, the HIP base protocol works well with any pair of co-operating end-hosts. However, to be more useful and more widely deployable, HIP needs some support from the existing infrastructure, including the DNS, and a new piece of infrastructure, called the HIP rendezvous server. Additionally, in order to facilitate experimenting with HIP, there is a need to study the interactions of HIP with legacy NATS and legacy applications, and to describe an API for HIP. +--+ | The purpose of this Working Group is to define the | | minimal elements that are needed for HIP experimentation | | on a wide scale. | +--+ In particular, the objective of this working group is to complete the base protocol specification, define one or more DNS resource records for storing HIP related data, complete the existing work on basic mobility and multi-homing, complete the work on NATs and on APIs, and produce Experimental RFCs for these. Note that even though the specifications are chartered for Experimental, it is understood that their quality and security properties should match the standards track requirements. The main purpose for producing Experimental documents instead of standards track ones are the unknown effects that the mechanisms may have on applications and on the Internet in the large. There is a roughly parallel, though perhaps considerably broader, IRTF Research Group that includes efforts both on developing the more forward looking aspects of the HIP architecture and on exploring the effects that HIP may have on applications and the Internet. Goals and Milestones: Mark as Done the following existing milestones: Oct 2005 WGLC the HIP registration extensions specification Oct 2005 WGLC the HIP DNS resource record(s) specification Oct 2005 WG LC on the basic HIP rendezvous mechanism specification. Nov 2005 Submit the ESP usage specification to the IESG for Experimental Nov 2005 Submit the base protocol specification to the IESG for Experimental Nov 2005 WG LC on the HIP basic mobility and multi-homing specification. Dec 2005 Submit the HIP registration extensions specification for Experimental Dec 2005 Submit the HIP DNS resource record(s) specification to the IESG for Experimental. Dec 2005 Submit the HIP basic mobility and multihoming specification to the IESG for Experimental. Dec 2005 Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental. Add the following new milestones: Jan 2007 WGLC Legacy NAT traversal specification Jan 2007 WGLC Legacy Application Interworking specification Jan 2007 WGLC Native API specification Mar 2007 Submit the Legacy NAT traversal specification to the IESG Mar 2007 Submit the Legacy Application Interworking specification to the IESG Mar 2007 Submit Native API specification to the IESG Change the date of the following milestone to Apr 2007 Jan 2006 Recharter or close the WG ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
