RE: REVISED Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0Authorization Protocol: Bearer Tokens) to Proposed Standard
Hi Francisco, if a token is created for access to server S1 and S2 then any party that gets access to the token can obviously access both servers. This should not be super surprising. So, if you have a deployment where you want to grant access to resources at multiple servers and the attack you describe is a concern then you need to create multiple tokens. The content of the token defines what the token can be used for. The bearer token specification does not define the content of the token and therefore it is difficult to say more about it beyond what it already says. If you think it is worth to specify highlight this type of attack then the appropriate place to describe it is the threats document. Ciao Hannes From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Francisco Corella Sent: Wednesday, February 01, 2012 6:53 AM To: ietf@ietf.org Subject: REVISED Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0Authorization Protocol: Bearer Tokens) to Proposed Standard The bearer token protocol described in the document referenced in the subject line is vulnerable to the following attack by a malicious resource server. There are two resource servers S1 and S2, S1 hosting a resource R1, and S2 hosting a resource R2. Servers are not entitled to access resources that they do not host. S1 is malicious. The client obtains a broadly scoped access token that allows access to both resources. The client uses the access token to obtain resource R1 from server S1. Malicious server S1 then presents the access token received from the client to server S2 and gains access to resource R2, which it is not entitled to access. Including the identity of the intended recipients in the token, as recommended in Section 4.2, does not help, since the intended recipients of the broadly scoped token include both R1 and R2. Francisco ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
I support the updates to this draft. Jinesh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: REVISED Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0Authorization Protocol: Bearer Tokens) to Proposed Standard
Hi Hannes, if a token is created for access to server S1 and S2 then any party that gets access to the token can obviously access both servers. This should not be super surprising. So, if you have a deployment where you want to grant access to resources at multiple servers and the attack you describe is a concern then you need to create multiple tokens. The content of the token defines what the token can be used for. The bearer token specification does not define the content of the token and therefore it is difficult to say more about it beyond what it already says. If you think it is worth to specify highlight this type of attack then the appropriate place to describe it is the threats document. Why shouldn't this attack be discussed in the security considerations section of the protocol spec? The security considerations section already addresses two closely related attacks: token redirect and token replay. It could use the following language to address together this attack and the token redirect attack: * If there are multiple resource servers, and different resource * servers provide client access to different resources, and resource * servers are not entitled to access resources others than those that * they provide client access to, then care must be taken to prevent a * malicious resource server from using an access token presented by a * client to access, through another resource server, a resource that * that the malicious server does not provide client access to. This * can be accomplished in two different ways: * * 1. By including in the access token a specification of the set of * resources that can be accessed by the token. The set must satisfy * the following condition: every resource server that provides * client access to a resource in the set must provide client access * to all the resources in the set. Or, * * 2. By including in the access token a specification of the set of * servers that the token can be presented to. A resource server * must verify that it is a member of the set when presented with the * token. The set must satisfy the following condition: all the * resource servers in the set must provide client access to the same * set of resources. Best, Francisco From: Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com To: Francisco Corella fcore...@pomcor.com; ietf@ietf.org Sent: Wednesday, February 1, 2012 4:33 AM Subject: RE: REVISED Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0Authorization Protocol: Bearer Tokens) to Proposed Standard Hi Francisco, if a token is created for access to server S1 and S2 then any party that gets access to the token can obviously access both servers. This should not be super surprising. So, if you have a deployment where you want to grant access to resources at multiple servers and the attack you describe is a concern then you need to create multiple tokens. The content of the token defines what the token can be used for. The bearer token specification does not define the content of the token and therefore it is difficult to say more about it beyond what it already says. If you think it is worth to specify highlight this type of attack then the appropriate place to describe it is the threats document. Ciao Hannes From:ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Francisco Corella Sent: Wednesday, February 01, 2012 6:53 AM To: ietf@ietf.org Subject: REVISED Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0Authorization Protocol: Bearer Tokens) to Proposed Standard The bearer token protocol described in the document referenced in the subject line is vulnerable to the following attack by a malicious resource server. There are two resource servers S1 and S2, S1 hosting a resource R1, and S2 hosting a resource R2. Servers are not entitled to access resources that they do not host. S1 is malicious. The client obtains a broadly scoped access token that allows access to both resources. The client uses the access token to obtain resource R1 from server S1. Malicious server S1 then presents the access token received from the client to server S2 and gains access to resource R2, which it is not entitled to access. Including the identity of the intended recipients in the token, as recommended in Section 4.2, does not help, since the intended recipients of the broadly scoped token include both R1 and R2. Francisco ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Wed, 1 Feb 2012, Brian E Carpenter wrote: On 2012-02-01 08:14, Pete Resnick wrote: On 1/31/12 11:59 AM, George, Wes wrote: From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Is that wise? I thought (IIRC, and maybe I'm spacing) the whole reason for allocating this space was that 1918 space _couldn't_ easily be used for CGN because there were too many conflicting usages. [WEG] yes, but the general sense I got from the ensuing discussion was that no one expects anyone to actually adhere to that advice (ie MUST NOT be used as substitute for 1918 space), and as soon as the space is released, it'll be cats and dogs living together, mass hysteria... because everyone and their cousin will start using it as 1918-bis anyway, no matter whether the IETF wags their fingers at them or not. I have no doubt that this space will be (mis)used as additional private ambiguous address space. But IMHO the text should make it clear that this is the wrong way to use it and give the reasons why - basically the same information as in the new text, but stated exactly the other way round. For example Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Shared Address Space is not intended to be used as additional [RFC1918] space, because either or both of the following issues might arise: o Shared Address Space could also be used on the Service Provider side of the CPE, with overlapping subnet or host addresses. o Some CPE routers behave incorrectly when using the same address block on both the internal and external interfaces. Speaking as one of the bozos^h^h^h^h^h ADs whose comments (and suggested text) ended the document up here, let me suggest the slightly less pessimistic view from Wes's, and the reason that I think this *shouldn't* specifically update 1918: This *is* a special use address block that is akin to 1918. It is non-routable address space, just like 1918. But unlike 1918, this block is defined as might be used by your ISP on your outside interface. So, people using it inside their networks (which, I agree with Wes, will happen, and like everything else on the net, will be done stupidly by some) have been told that this is *not* private use space and that they use it at their own risk and their CGN service might stop working if they use it in a way not described in this document. But I'd hate for us to allocate space to CGNs only when it's obvious that this can be used for a whole class of these sorts of things, and can be used by other people who build sane equipment that understands shared addresses can appear on two different interfaces. These aren't private addresses a la 1918, they're shared, so it's not an addition to that space. Let's properly document what it is we're doing, giving people fair warnings. Exactly, hence my suggested text above. +1 //cmh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 1/31/12 1:38 PM, Brian E Carpenter wrote: IMHO the text should make it clear that this is the wrong way to use it and give the reasons why - basically the same information as in the new text, but stated exactly the other way round. For example Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Shared Address Space is not intended to be used as additional [RFC1918] space, because either or both of the following issues might arise: o Shared Address Space could also be used on the Service Provider side of the CPE, with overlapping subnet or host addresses. o Some CPE routers behave incorrectly when using the same address block on both the internal and external interfaces. Ah. I think we're in pretty good agreement. The -14 text uses the words may be used as [RFC1918] private address space, and I agree with you that we don't want to use those words. We need to say that though it is similar to 1918 space, it has limitations. So I wouldn't object to the above text , but I think we do have to give some indication of the flip side. I want something that says that Shared Address Space can be used for other Service-Provider-type uses and are not limited to CGNs. They can be used on any network equipment willing to do address translation across interfaces which both use the Shared Address Space, just as CGNs do. That is, clarify throughout that this *isn't* just like 1918 space (it has limitations and can only be used in particular circumstances), but do describe what the conditions are under which it can be used. In your above, I would even strengthen is not intended to be used as additional [RFC1918] space to can not be use as [RFC1918] private address space, and then maybe add something about where it can be used. In the intro, I would change the second paragraph (and it's sub-bullets) to: Shared Address Space is similar to [RFC1918] private address space in that it is not global routeable address space and can be used by multiple pieces of equipment. However, Shared Address Space has limitations in its use that the current [RFC1918] private address space does not have. In particular, Shared Address Space can only be used on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Or something to that effect. Does that still capture that Shared Address Space is similar to 1918 space, it can be used for purposes other than CGN, but it can't be used everywhere 1918 addresses are used? pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Pete, We seem to be agreeing violently. Regards Brian Carpenter On 2012-02-02 11:33, Pete Resnick wrote: On 1/31/12 1:38 PM, Brian E Carpenter wrote: IMHO the text should make it clear that this is the wrong way to use it and give the reasons why - basically the same information as in the new text, but stated exactly the other way round. For example Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Shared Address Space is not intended to be used as additional [RFC1918] space, because either or both of the following issues might arise: o Shared Address Space could also be used on the Service Provider side of the CPE, with overlapping subnet or host addresses. o Some CPE routers behave incorrectly when using the same address block on both the internal and external interfaces. Ah. I think we're in pretty good agreement. The -14 text uses the words may be used as [RFC1918] private address space, and I agree with you that we don't want to use those words. We need to say that though it is similar to 1918 space, it has limitations. So I wouldn't object to the above text , but I think we do have to give some indication of the flip side. I want something that says that Shared Address Space can be used for other Service-Provider-type uses and are not limited to CGNs. They can be used on any network equipment willing to do address translation across interfaces which both use the Shared Address Space, just as CGNs do. That is, clarify throughout that this *isn't* just like 1918 space (it has limitations and can only be used in particular circumstances), but do describe what the conditions are under which it can be used. In your above, I would even strengthen is not intended to be used as additional [RFC1918] space to can not be use as [RFC1918] private address space, and then maybe add something about where it can be used. In the intro, I would change the second paragraph (and it's sub-bullets) to: Shared Address Space is similar to [RFC1918] private address space in that it is not global routeable address space and can be used by multiple pieces of equipment. However, Shared Address Space has limitations in its use that the current [RFC1918] private address space does not have. In particular, Shared Address Space can only be used on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Or something to that effect. Does that still capture that Shared Address Space is similar to 1918 space, it can be used for purposes other than CGN, but it can't be used everywhere 1918 addresses are used? pr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Nomcom 2011-2012: IAB Appointments
Hi all, The 2011-2012 IETF Nominating committee is pleased to announce the selection of the IAB members whose two year terms start at IETF83. The Nomcom has selected the following persons to serve as members of the IAB and they have been confirmed by the ISOC Board of Trustees (in its role as the confirming body): Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Spencer Dawkins Hannes Tschofenig We would like to express our sincere gratitude to the incumbents who are not returning for their outstanding service, the many highly qualified members of the community who offered to serve, the community for their assistance in this process, and the individuals named above for agreeing to serve the community on the IAB. Suresh Krishnan Chair, NomCom 2011-2012 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt (Considerations for Transitioning Content to IPv6) to Informational RFC
The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Considerations for Transitioning Content to IPv6' draft-ietf-v6ops-v6--whitelisting-implications-08.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-02-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes considerations for the transition of end user content on the Internet to IPv6. While this is tailored to address end user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6--whitelisting-implications/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6--whitelisting-implications/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BFCPBIS WG Virtual Interim Meeting: Tuesday, February 21, 8-10am PST
The BFCPBIS Working Group will hold a virtual interim meeting on Tuesday, February 21, from 8-10am PST. The virtual interim will be conducted via WebEx, the details for which are attached to this e-mail. It is generally best if you join via the link provided, and then allow the system to call you back. You can dial in manually as well if necessary. The proposed agenda is as follows: 1) Note well 2) Agenda bash 3) Status 4) Proposed document structure / working method to produce bis version. 5) Technical discussion on draft (http://tools.ietf.org/wg/bfcpbis/) -+-+-+-+-+-+-+-+-+- [Do not add or change anything below this line. The information in this section may be replaced with your meeting details after you click Send.] You scheduled this meeting. Meeting Number: 202 706 234 Meeting Password: bfcpbis --- To start this meeting --- 1. Go to https://cisco.webex.com/cisco/j.php?J=202706234PW=NMDA0YmQ0N2I0 2. Log in to your account. 3. Click Start Now. 4. Follow the instructions that appear on your screen. ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 --- To join the teleconference only --- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350. Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 http://www.webex.com CCM:+14085256800x202706234# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6508 on Sakai-Kasahara Key Encryption (SAKKE)
A new Request for Comments is now available in online RFC libraries. RFC 6508 Title: Sakai-Kasahara Key Encryption (SAKKE) Author: M. Groves Status: Informational Stream: IETF Date: February 2012 Mailbox:michael.gro...@cesg.gsi.gov.uk Pages: 21 Characters: 42700 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-groves-sakke-03.txt URL:http://www.rfc-editor.org/rfc/rfc6508.txt In this document, the Sakai-Kasahara Key Encryption (SAKKE) algorithm is described. This uses Identity-Based Encryption to exchange a shared secret from a Sender to a Receiver. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6509 on MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY)
A new Request for Comments is now available in online RFC libraries. RFC 6509 Title: MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY) Author: M. Groves Status: Informational Stream: IETF Date: February 2012 Mailbox:michael.gro...@cesg.gsi.gov.uk Pages: 21 Characters: 47389 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-groves-mikey-sakke-03.txt URL:http://www.rfc-editor.org/rfc/rfc6509.txt This document describes the Multimedia Internet KEYing-Sakai-Kasahara Key Encryption (MIKEY-SAKKE), a method of key exchange that uses Identity-based Public Key Cryptography (IDPKC) to establish a shared secret value and certificateless signatures to provide source authentication. MIKEY-SAKKE has a number of desirable features, including simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6518 on Keying and Authentication for Routing Protocols (KARP) Design Guidelines
A new Request for Comments is now available in online RFC libraries. RFC 6518 Title: Keying and Authentication for Routing Protocols (KARP) Design Guidelines Author: G. Lebovitz, M. Bhatia Status: Informational Stream: IETF Date: February 2012 Mailbox:gregory.i...@gmail.com, manav.bha...@alcatel-lucent.com Pages: 30 Characters: 76782 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-karp-design-guide-10.txt URL:http://www.rfc-editor.org/rfc/rfc6518.txt This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Keying and Authentication for Routing Protocols Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6528 on Defending against Sequence Number Attacks
A new Request for Comments is now available in online RFC libraries. RFC 6528 Title: Defending against Sequence Number Attacks Author: F. Gont, S. Bellovin Status: Standards Track Stream: IETF Date: February 2012 Mailbox:fg...@si6networks.com, bello...@acm.org Pages: 12 Characters: 26917 Obsoletes: RFC1948 Updates:RFC0793 I-D Tag:draft-ietf-tcpm-rfc1948bis-02.txt URL:http://www.rfc-editor.org/rfc/rfc6528.txt This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. [STANDARDS-TRACK] This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2011-2012: IAB Appointments
Hi all, The 2011-2012 IETF Nominating committee is pleased to announce the selection of the IAB members whose two year terms start at IETF83. The Nomcom has selected the following persons to serve as members of the IAB and they have been confirmed by the ISOC Board of Trustees (in its role as the confirming body): Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Spencer Dawkins Hannes Tschofenig We would like to express our sincere gratitude to the incumbents who are not returning for their outstanding service, the many highly qualified members of the community who offered to serve, the community for their assistance in this process, and the individuals named above for agreeing to serve the community on the IAB. Suresh Krishnan Chair, NomCom 2011-2012 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
