From shpark at kisa.or.kr Tue Oct 17 06:56:18 2006 From: shpark at kisa.or.kr (=?ks_c_5601-1987?B?udq788iv?=) Date: Tue, 17 Oct 2006 22:56:18 +0900 Subject: [anonsec] Subscribe Message-ID: <029001c6f1f4$04d044b0$690710ac@5428c1> shpark at kisa.or.kr Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/anonsec/attachments/20061017/f1dd7b01/attachment.html From mcr at sandelman.ottawa.on.ca Wed Oct 18 19:05:53 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Wed, 18 Oct 2006 22:05:53 -0400 Subject: [anonsec] I-D Submission: Extension of ICMP Security Failures Messages References: <9570C1261494D54D9D3115BC2C83429A09D608@asbmail2.sbell.com.cn> Message-ID: >>>>> "CTO" == CTO ZHANG Qingshan writes: CTO> Hi, dear all, I just submitted an I-D to this WG of btns. Here's a CTO> brief introduction of this I-D and the reason why I choose this CTO> group for this submission. CTO> 1. This I-D is about icmp message extension for IPSec failure CTO> reporting. It is closely tied with the IPSec protocol suite which is CTO> used for trouble shooting when IPSec (both the traditional IPSec CTO> (authenticated SA) and the new one proposed by this WG CTO> (unauthenticated SA)) is deployed for secure communications. With I scanned your document quickly. You'll need to tell us who is sending, and who is receiving, and why the receiver can expect to trust the information being provided. If the receiver can not trust that the ICMP is legitimate, then you need to tell us what behaviour the sender should take to verify that the complaint is legitimate, or what things it might do. Assume that all ICMP messages can be forged. From miika at iki.fi Fri Oct 27 01:23:36 2006 From: miika at iki.fi (Miika Komu) Date: Fri, 27 Oct 2006 11:23:36 +0300 (EEST) Subject: [anonsec] IPsec Application Programming Interfaces Message-ID: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPsec Application Programming Interfaces Author(s) : M. Komu Filename : draft-komu-btns-api-00.txt Pages : 13 Date : 2006-10-9 Usually network layer security through IPsec is transparent for applications. Usually, they cannot detect the presence of IPsec or affect its security properties. This document specifies extensions to increase the visibility of IPsec to applications through a low level sockets API. In addition, a higher layer APIs based on GSS is also defined. The GSS based APIs increase security level of the application through the dual use of both transport and network layer security. It can be also used to improve protocol performance by reducing redundant authentications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-komu-btns-api-00.txt -- Miika Komu http://www.iki.fi/miika/