From mcr at sandelman.ca Fri May 11 15:56:54 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 11 May 2007 18:56:54 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> <8083.1175706591@sandelman.ottawa.on.ca> Message-ID: Stephen Kent wrote: >> Stephen> Does the spec say that it is used ONLY by a responder? If >> Stephen> so, then your wording sounds better. If not, ... >> > At 1:09 PM -0400 4/4/07, Michael Richardson wrote: >> 1) BTNS says nothing about how nodes know to do BTNS. We explicitely >> left out discovery. >> So, an initiator would have to some some PAD/SPD entry that told it >> to do something. >> >> If that thing was "PROTECT IF REQUESTED", and the application >> requested protection, then that wording would fit. Stephen Kent wrote: > I was focusing on the requester being the peer, not the application > triggering SA creation. > > I am still a bit confused. Are you saying that if an app requests > IPsec protection for a connection then this entry will try to create > an SA, but it will not try to create an SA if the app does not > request it? I guess I tend to think in PAD/SPD -centric terms, not Yes. This is not the same as inserting a PAD/SPD entry that creates an SA upon the first packet (with or without the "populate from packet" option). > I also see a possible disconnect here. Consider an SPD entry that > supports our new "PROTECT IF X" feature and that entry is a tunnel > for ALL TCP traffic between Host A and Host B. Let's say that one app I agree that we need to decide whether or not to "migrate" the traffic or not. This is an interoperability issue. The applications which did *NOT* request the SA, are presumably happy (i.e. "secure") even if they don't get IPsec protection. Probably they don't even know anything about it. How is this any different than suddenly turning on that bump-in-the-wire site-to-site IPsec gateway? I don't like the term "migrate", because I wouldn't have had a "BYPASS" entry for the traffic in the clear. The traffic went in the clear because it fell off the end of the SPD, and the default was clear (vs drop). > does not request an SA between A and B, and so an unprotected TCP > connection is established. Then a second app requests an SA, if > possible. Do we create a tunnel and migrate the old, unprotected > traffic to the tunnel? If not, we would seem to have a conflict > between two SAD entries, one labelled BYPASS and one ESP, with the > same scope (based on the SPD entry I described above). have we > discussed this scenario before, and if so, what was the conclusion? > From mcr at sandelman.ottawa.on.ca Fri May 11 19:11:00 2007 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri, 11 May 2007 22:11:00 -0400 Subject: [anonsec] suggested changes to btns-api-01 Message-ID: <18558.1178935860@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (new abstract-api document at, which is background to below at: http://www.sandelman.ca/SSW/ietf/ipsec/btns/richardson-btns-abstract-api-00.txt ) > 2.1.1 Policy Creation. change: typedef ipsec_policy_t struct ipsec_policy; to: typedef struct ipsec_iToken * ipsec_iToken_t; #define IPSEC_ITOKEN_INVALID NULL change: ipsec_policy_t *ipsec_create_policy(uint32_t type); int ipsec_free_policy(ipsec_policy_t *policy); to: ipsec_iToken_t ipsec_iToken_alloc(uint32_t type); int ipsec_iToken_free(ipsec_iToken_t i); COMMENT: Can you give me a use case for the "type" argument? vs having new creation functions? > 2.1.2 change: int ipsec_get_policy_attr(const ipsec_policy_t *policy, uint32_t attr_type, uint32_t *attr_len, void **attr_val); int ipsec_set_policy_attr(ipsec_policy_t *policy, uint32_t attr_type, uint32_t attr_len, const void *attr_val); to: int ipsec_iToken_attr_get(const ipsec_iToken_t iToken, enum iToken_attribute, size_t *attr_len, /* VALUE/RESULT */ void **attr_val); int ipsec_iToken_attr_set(const ipsec_iToken_t iToken, enum iToken_attribute attr_type, size_t attr_len, const void *attr_val); change: Function ipsec_get_policy_attr searches for the given attribute type (attr_type) from the policy. It allocates memory into attr_val and copies the attribute into the allocated memory. On successful operation, it sets the attribute length in attr_len. to: Function ipsec_pToken_attr_get searches for the given attribute type (attr_type) from the pToken. The *attr_val pointer may have memory allocated for it already, if so, it will be non-NULL, and the attr_len will have the size of the allocated memory set. If *attr_val is NULL, then it allocates memory into attr_val (using malloc) and copies the attribute into the allocated memory. On successful operation, it sets the attribute length in attr_len. If attr_val is NULL, then no object will be returned, but attr_len will still be set to the size of the object. COMMENT: I don't understand what BTNS_STANDALONE attribute would mean. >2.1.3 change: int ipsec_set_socket_policy(int fd, const ipsec_policy_t *policy); int ipsec_get_socket_policy(int fd, ipsec_policy_t **policy); to: const ipsec_iToken_t ipsec_iToken_from_pToken(ipsec_pToken_t p); int ipsec_pToken_for_socket(int fd, ipsec_pToken_t *policy); NOTE: this is really a wrapper around: ipsec_pToken_attr_get(pToken, IPSEC_API_ATTR_ITOKEN, &iToken, sizeof(iToken)); >2.1.5 change: 2.1.5. Other Policy Related Functions to: 2.1.5. Equivalency of policies change: int ipsec_cmp_policy(ipsec_policy_t *p1, ipsec_policy_t *p2); Function ipsec_cmp_policy inputs two policies, p1 and p2, and returns zero if they are equal. Otherwise it returns non-zero. to: int ipsec_pToken_cmp(ipsec_pToken_t p1, ipsec_pToken_t p2); int ipsec_iToken_cmp(ipsec_iToken_t p1, ipsec_iToken_t p2); Function ipsec_cmp_policy inputs two policies, p1 and p2, and returns zero if they represent two SAs that cover identical SPD ranges, and have equivalent cryptographic security properties. The two SAs need not represent SAs that identical --- they might vary in many different ways, including, but not limited to: - time. One SA may have been created later, but both are valid. - jitter/performance properties. One SA may be on hardware and the other on software, and have different properties about what kind of latency or jitter a packet might experience. - algorithm. one SA might use AES128-CBC while the other uses AES128-CTR (DISCUSS) for performance reasons. - IPsec SA endpoints. The two SAs may cover the same inner IP packets, but might connect using differing outer IP addresses, and be used in some kind of multipath IPsec (such as MOBIKE). XXX -- belongs in abstract document. are equal. Otherwise it returns non-zero. MOVE ipsec_dup_policy to seperate section (2.1.6) >new section 2.1.7 ATTRIBUTES for iToken enum { IPSEC_API_ATTR_auditString, IPSEC_API_ATTR_authenticationMethod, IPSEC_API_ATTR_certificateAuthorityDN, IPSEC_API_ATTR_certificateDN, IPSEC_API_ATTR_pubKeyID, IPSEC_API_ATTR_channelBinding, } iToken_attribute; enum { IPSEC_API_authMeth_NONE, IPSEC_API_authMeth_BTNS, IPSEC_API_authMeth_LEAFOFFAITH, IPSEC_API_authMeth_PRESHAREDKEY, IPSEC_API_authMeth_GROUPKEY, IPSEC_API_authMeth_XAUTH, IPSEC_API_authMeth_EAP, IPSEC_API_authMeth_PKIX_TRUSTED, IPSEC_API_authMeth_PKIX_INLINE, IPSEC_API_authMeth_PKIX_OFFLINE } iToken_auth_meth; >2.2.1 change: typedef ipsec_channel_info_t struct ipsec_channel_info; to: typedef struct ipsec_pToken * ipsec_pToken_t; #define IPSEC_PTOKEN_INVALID NULL change: ipsec_channel_info_t *ipsec_create_channel_info(); int ipsec_free_channel_info(*ipsec_channel_info_t *ci); to: ipsec_pToken_t ipsec_pToken_alloc(void); int ipsec_pToken_free(ipsec_pToken_t p); >2.2.2 change: int ipsec_set_channel_attr(ipsec_channel_info_t *ci, uint32_t attr_type, uint32_t attr_len, const void *attr_val); int ipsec_get_channel_attr(const ipsec_channel_info_t *ci, uint32_t attr_type, uint32_t *attr_len, void **attr_val); to: int ipsec_pToken_attr_get(const ipsec_pToken_t pToken, enum pToken_attribute, size_t *attr_len, /* VALUE/RESULT */ void **attr_val); int ipsec_pToken_attr_set(const ipsec_pToken_t pToken, enum pToken_attribute attr_type, size_t attr_len, const void *attr_val); (and indicate that **attr_val may be filled in, a la iToken) >2.2.3 change: int ipsec_set_socket_policy(int fd, const ipsec_policy_t *policy); int ipsec_get_socket_policy(int fd, ipsec_policy_t **policy); to: const ipsec_pToken_t ipsec_pToken_from_socket(int fd); int ipsec_pToken_for_socket(int fd, ipsec_pToken_t *policy); The function ipsec_pToken_from_socket() returns IPSEC_PTOKEN_INVALID upon failure. XXX need to have extended error reporting... >2.2.4 change: int ipsec_set_msg_channel_info(const struct *msg_hdr, const ipsec_channel_info_t *ci); int ipsec_get_msg_channel_info(const struct *msg_hdr, ipsec_channel_info_t **ci); to: pToken_t ipsec_pToken_from_cmsg(struct msghdr *msg); int ipsec_pToken_for_cmsg(struct msghdr *msg); >2.2.5 same as 2.1.5... >2.1.7, new section, ATTRIBUTES: enum { IPSEC_API_ATTR_privacyProtected, IPSEC_API_ATTR_integrityProtected, IPSEC_API_ATTR_compressionAvailable, IPSEC_API_ATTR_iToken, IPSEC_API_ATTR_auditString } pToken_attribute; - -- ] Bear: "Me, I'm just the shape of a bear." | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRkUiMoCLcPvd0N1lAQJSTQf+O39QC4m/y//DjsM1qTKZJ70jOX/odxj5 Hp2ekQhFPpWq+wBtPvz/2W3viHiDUMLj/n4UvkdLKeSt+NPIBt/amUbQEe8tdTxk sUNeg0n0jvuuM4ndhlipi8w/nb1E1yd3X5440edLnSznZJ3W9iDVeJbl5JN8zmv9 kq0mKB/Gr673BbLFqHlfQhwt/ymN61B1AY4D1RHkIiqwp+CiSQxHQgZpAh9CRl1r u2vTYeounzoMBfXjp8vdR3Dez0fSwMRWF4wBu2SClhfVH8Oax8OSfweAByBt0Yd9 xwDcG+4KhvYLMyDh1/UQePcMPeB25uWR8z3yUCJmZ9iISXYOUjBIHg== =K29c -----END PGP SIGNATURE----- From mcr at sandelman.ca Sat May 12 15:11:58 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Sat, 12 May 2007 18:11:58 -0400 Subject: [anonsec] draft-richardson-btns-ikeextensions-00 In-Reply-To: <46134B6F.8090904@checkpoint.com> References: <46134B6F.8090904@checkpoint.com> Message-ID: Yaron Sheffer wrote: > Mostly nits, some bigger comments. > > * If the use of Raw RSA is "clarified", shouldn't this draft > "update" RFC 4306 (or worse, RFC 4718)? I guess so. > * Sec. 2: "It *SHOULD be sent in after *the phase 1 SA has become > private," - I guess you mean "SHOULD be sent *only* after. fixed. > * Typo: "Aggressive mode *is *SHOULD NOT". fixed. > * Sec. 3: "This code point is hereby defined for IKEv1" - this > should also go into the IANA Considerations. I'm not certain about this because we never created all the appropriate IKEv1 registries. > * KEY is capitalized a number of times. bad habit from doing DNS related drafts... > * Sec. 5: "It details the order in which to look for authentication > data for a protocol which does not in itself require any > authentication data." This sentence baffled me. What do you mean? > Does this imply that no further security analysis is required? This document doesn't change IKE. (BTNS itself does though) So, if the protocol was secure before, then it is secure now. It simply tells one how to interpret a key found in a particular type of certificate payload. It also provides an indication (for a human), that the peer thinks it is doing BTNS. The node receiving that message may or may not be in BTNS mode, but none of the contents of the IKE payload would change that for the peer. If you think more discussion needs to go into this document, tell me what kind of things you think go here. http://www.sandelman.ca/SSW/ietf/ipsec/btns/richardson-btns-ikeextensions-01.txt (not yet submitted) From shinta at sfc.wide.ad.jp Sun May 13 07:10:52 2007 From: shinta at sfc.wide.ad.jp (Shinta Sugimoto) Date: Sun, 13 May 2007 23:10:52 +0900 Subject: [anonsec] question: ID payload in BTNS IKE negotiation Message-ID: <20070513223149.66EE.SHINTA@sfc.wide.ad.jp> Hello, I have a basic question about BTNS IKE negotiation. In BTNS IKE negotiation, what should ID payload (IDi/IDr) be? I understand that public key is the instance which represents identity of the host in BTNS. But reading the spec, I did not fully understand how IKE negotiation is done in particular usage of ID payload. My interpretation of the spec is that an identity of a peer (=public key) is represented by the CERT payload. If so, what is the role of ID payload in BTNS IKE negotiation? And what should be included in the IDi, IDr? Thank you in advance. Regards, Shinta From mcr at sandelman.ca Sun May 13 16:51:50 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Sun, 13 May 2007 19:51:50 -0400 Subject: [anonsec] question: ID payload in BTNS IKE negotiation In-Reply-To: <20070513223149.66EE.SHINTA@sfc.wide.ad.jp> References: <20070513223149.66EE.SHINTA@sfc.wide.ad.jp> Message-ID: Shinta Sugimoto wrote: > In BTNS IKE negotiation, what should ID payload (IDi/IDr) be? > I understand that public key is the instance which represents > identity of the host in BTNS. But reading the spec, I did not fully To first order, it shouldn't matter, however that will lead to interoperability issues. My suggestion is that it should be IPV4/IPV6_ID of the host. > understand how IKE negotiation is done in particular usage of ID > payload. My interpretation of the spec is that an identity of > a peer (=public key) is represented by the CERT payload. If so, > what is the role of ID payload in BTNS IKE negotiation? > And what should be included in the IDi, IDr? The ID payload tells you how to look up the policy in the PAD. You will have to look into the PAD at least, to discover that you had no explicit policy for this peer, and that therefore, it should be put into "BTNS" category. From shinta at sfc.wide.ad.jp Mon May 14 00:59:53 2007 From: shinta at sfc.wide.ad.jp (Shinta Sugimoto) Date: Mon, 14 May 2007 16:59:53 +0900 Subject: [anonsec] question: ID payload in BTNS IKE negotiation In-Reply-To: References: <20070513223149.66EE.SHINTA@sfc.wide.ad.jp> Message-ID: <20070514165924.6713.SHINTA@sfc.wide.ad.jp> Hello Michael, Thank you for the response. Please find my comments inline. On Sun, 13 May 2007 19:51:50 -0400 Michael Richardson wrote: > Shinta Sugimoto wrote: > > In BTNS IKE negotiation, what should ID payload (IDi/IDr) be? > > I understand that public key is the instance which represents > > identity of the host in BTNS. But reading the spec, I did not fully > > To first order, it shouldn't matter, however that will lead to > interoperability issues. I see. So the spec should be clear on this point. > > My suggestion is that it should be IPV4/IPV6_ID of the host. Hmm. This seems to me fine for static and/or single-homed environment, but not ideal for mobile and/or multihomed environment (e.g. RFC 4555) where IP address is not suitable for the purpose of identifying peers. So, I think it would be better to use something different than IP address for ID payload although I don't have good answer either at the moment. > > > understand how IKE negotiation is done in particular usage of ID > > payload. My interpretation of the spec is that an identity of > > a peer (=public key) is represented by the CERT payload. If so, > > what is the role of ID payload in BTNS IKE negotiation? > > And what should be included in the IDi, IDr? > > The ID payload tells you how to look up the policy in the PAD. Yes, that is true. And the use of identifier which is based on IP address (ID_IPV4_ADDR/ID_IPV6_ADDR) will limit the applicability of BTNS to static/single-homed environment as I mentioned above. > You will have to look into the PAD at least, to discover that you had no > explicit policy for this peer, and that therefore, it should be put into > "BTNS" category. Yes. I still need clarification of the intention of BTNS spec for ID. The spec (draft-btns-core-02) says: > 2. BTNS > > The IPsec processing model, IKE and IKEv2 are hereby modified as > follows: > > o A new ID type is added, 'PUBLICKEY'; IDs of this type have public > keys as values. This ID type is not used on the wire. I assume that the above sentence recommends not to use ID_PUBLICKEY as an ID payload. If so, what is the reason behind? I see that it (including ID_PUBLICKEY in ID payload) would simply be a duplication because the public key is to be stored in CERT payload, but I believe it still makes sense to use ID type which is independent from IP address for ID payload. Any comments? Regards, Shinta From Internet-Drafts at ietf.org Wed May 16 12:50:02 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed, 16 May 2007 15:50:02 -0400 Subject: [anonsec] I-D ACTION:draft-ietf-btns-core-03.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-core-03.txt -------------- next part -------------- From wang.yushun at gmail.com Mon May 21 00:22:55 2007 From: wang.yushun at gmail.com (Yu-Shun Wang) Date: Mon, 21 May 2007 00:22:55 -0700 Subject: [anonsec] AD Review: Probably and Applicability Statement In-Reply-To: References: Message-ID: <465148CF.9070207@gmail.com> Hi Sam, Thanks for the reviews. Some comments inline. Sam Hartman wrote: > > Hi, folks. I've finished reviewing the Problem and Applicability > Statement draft. > > I'd like to thank the authors for a lot of good work. > > Several of the comments I made in my first review of the document > still haven't been fixed. Terms like flash crowd, DDOS, zombies are > not defined before they are used. Unless someone can provide citations, I am going to replace these terms as below: s/flash crowd/unexpected surge of legitimate requests/ s/zombies/compromised systems/ s/DDoS/distributed denial of service/ (Seriously, do we still have to explain DDoS here? Or we just need to spell it out?) > Section 5.3 claims that passwords over anonymous channels are > inappropriate. I don't think there is an ietf consensus behind this. > Replace old: Therefore, CBB must not be used with higher layer > protocols that may expose sensitive information during authentication > exchange. > > with new: Therefore, CBB must not be used with higher layer protocols > that may expose sensitive information during authentication exchange > where the exposure of this information presents an unacceptable > security risk. Will do. Thanks for the text. > I wonder if the working group has adequately reviewed section 5.7. > In particular do we actually have a strong consensus that caching of > BTNS credentials is inappropriate? We certainly have a lot of issues > to work through before we can recommend this caching. But if there is > no caching how is that leap of faith at all? At our original draft draft, I left it as "?" (or TBD) We can change it back to TBD. The text (as I remembered) deliberately does NOT take a position on the debate of what LoF is between the two mechanisms: accepting the unauth ID vs. caching it (and treating it differently next time). We just explained what the two mechanisms are and stated the status of our understanding. I am personally neutral to this. It's the WG's call. By the way, we (the authors) went through a lot of discussion to keep the position neutral, stating the issues involved and what will need to happen (at a very high level) to make it work or secure. IIRC we didn't shut the door so to speak. > If there is such a consensus then Section 5.7 should be removed and a > section added to the applicability statement saying that leap of > faith/credential caching is out of scope. I'd appreciate if such text doesn't involve why it's out of scope. Otherwise we'd be repeating the current 5.7 again. > Section 6 rules mobility, nat and multihoming out of scope. Please > provide an argument that btns does not make issues associated with > nat and multihoming worse. IN particular think about address > selection for inner addresses with anonymous open services and show > that this problem is not worse in a BTNS universe. I am no expert to all of those. Text suggestion? (I thought those were not in the charter, didn't realize we have to explain why they are not in the charter.) > If you can do that then you can attempt to rule NAT and > multihoming/mobility out of scope. I'll still call it out in the > IETF last call message and confirm that the community is willing to > let you rule this out of scope. Sure. Thanks, yushun From hartmans-ietf at mit.edu Mon May 21 07:57:10 2007 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Mon, 21 May 2007 10:57:10 -0400 Subject: [anonsec] AD Review: Probably and Applicability Statement In-Reply-To: <465148CF.9070207@gmail.com> (Yu-Shun Wang's message of "Mon, 21 May 2007 00:22:55 -0700") References: <465148CF.9070207@gmail.com> Message-ID: >>>>> "Yu-Shun" == Yu-Shun Wang writes: Yu-Shun> Hi Sam, Thanks for the reviews. Some comments inline. Yu-Shun> Unless someone can provide citations, I am going to Yu-Shun> replace these terms as below: Yu-Shun> s/flash crowd/unexpected surge of legitimate requests/ Yu-Shun> s/zombies/compromised systems/ s/DDoS/distributed denial Yu-Shun> of service/ Yu-Shun> (Seriously, do we still have to explain DDoS here? Or we Yu-Shun> just need to spell it out?) Spelling it out is sufficient. >> I wonder if the working group has adequately reviewed section >> 5.7. In particular do we actually have a strong consensus that >> caching of BTNS credentials is inappropriate? We certainly >> have a lot of issues to work through before we can recommend >> this caching. But if there is no caching how is that leap of >> faith at all? Yu-Shun> At our original draft draft, I left it as "?" (or TBD) We Yu-Shun> can change it back to TBD. Yu-Shun> The text (as I remembered) deliberately does NOT take a Yu-Shun> position on the debate of what LoF is between the two Yu-Shun> mechanisms: accepting the unauth ID vs. caching it (and Yu-Shun> treating it differently next time). We just explained Yu-Shun> what the two mechanisms are and stated the status of our Yu-Shun> understanding. I am personally neutral to this. It's the Yu-Shun> WG's call. Yu-Shun> By the way, we (the authors) went through a lot of Yu-Shun> discussion to keep the position neutral, stating the Yu-Shun> issues involved and what will need to happen (at a very Yu-Shun> high level) to make it work or secure. IIRC we didn't Yu-Shun> shut the door so to speak. That's not how the section currently reads at all. The last sentence tries to keep the door open but really does not interact well with the table where you say that caching cannot be done in BTNS. The section also does not discuss the problems with unauthenticated credentials. IT says what extra work is needed but not really why. Extra work includes: * A Mechanism for user acceptance before caching * How do you know when you are talking to the same peer (mobility/address ownership issues) * How do you support key rollover/what do you say about this IMHO, you're not done with this section. If the authors don't have the experiense internally to complete this section then the WG needs to provide that. >> Section 6 rules mobility, nat and multihoming out of scope. >> Please provide an argument that btns does not make issues >> associated with nat and multihoming worse. IN particular think >> about address selection for inner addresses with anonymous open >> services and show that this problem is not worse in a BTNS >> universe. Yu-Shun> I am no expert to all of those. Text suggestion? You need to get someone to do the engineering work first. I.E. I think it may well be the case that BTNS creates problems in these areas that need to be addressed. Someone in the WG actually needs to work through these issues enough to figure out whether that's the case. I simply provided requirements you'd need to meet if you want to take the current direction. Yu-Shun> (I thought those were not in the charter, didn't realize Yu-Shun> we have to explain why they are not in the charter.) As far as I can tell the charter does not speak to these issues one way or the other. If you think it does please point out the text in the charter that speaks to this issue so I can take a look at whether I'm asking you to go beyond your charter. Yu-Shun> Thanks, Yu-Shun> yushun Thanks again for excellent work. From julien.IETF at laposte.net Tue May 22 01:28:31 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Tue, 22 May 2007 10:28:31 +0200 Subject: [anonsec] I-D ACTION:draft-ietf-btns-core-03.txt In-Reply-To: References: Message-ID: <200705221028.31721.julien.IETF@laposte.net> Folks, This document has been submitted to IESG for publication as proposed standard. Attached is the publication request's write-up. -- julien / BTNS co-chair On Wednesday 16 May 2007 21:50, Internet-Drafts at ietf.org wrote: > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Better-Than-Nothing > Security Working Group of the IETF. > > Title : Better-Than-Nothing-Security: An > Unauthenticated Mode of IPsec Author(s) : M. > Richardson, N. Williams > Filename : draft-ietf-btns-core-03.txt > Pages : 15 > Date : 2007-5-16 > > This document specifies how to use the Internet Key > Exchange (IKE) protocols, such as IKEv1 and IKEv2, > to setup "unauthenticated" security associations > (SAs) for use with the IPsec Encapsulating Security > Payload (ESP) and the IPsec Authentication Header > (AH). No IKE extensions are needed, but Peer > Authorization Database (PAD) and Security Policy > Database (SPD) extensions are specified. > Unauthenticated IPsec is herein referred to by its > popular acronym, "BTNS" (Better Than Nothing > Security). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-btns- >core-03.txt > > To remove yourself from the I-D Announcement list, > send a message to i-d-announce-request at ietf.org with > the word unsubscribe in the body of the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. > Login with the username "anonymous" and a password > of your e-mail address. After logging in, type "cd > internet-drafts" and then "get > draft-ietf-btns-core-03.txt". > > A list of Internet-Drafts directories can be found > in http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE > /internet-drafts/draft-ietf-btns-core-03.txt". > > NOTE: The mail server at ietf.org can return the > document in MIME-encoded form by using the "mpack" > utility. To use this feature, insert the command > "ENCODING mime" before the "FILE" command. To > decode the response(s), you will need "munpack" or a > MIME-compliant mail reader. Different > MIME-compliant mail readers exhibit different > behavior, especially when dealing with "multipart" > MIME messages (i.e. documents which have been split > up into multiple messages), so check your local > documentation on how to manipulate these messages. > > Below is the data which will enable a MIME compliant > mail reader implementation to automatically retrieve > the ASCII version of the Internet-Draft. -------------- next part -------------- (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The Document Shepherd for this document is Julien Laganier, BTNS co-chair, who reviewed this version of the document and believes this version is ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document had review from both inside and outside the WG. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG is behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes (The document has no normative references). (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Yes (The document has no IANA considerations). (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes (The document does not contain formal language). (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The Internet network security protocol suite, IPsec, consisting of IKE, ESP, and AH, generally requires authentication of network layer entities to bootstrap security. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates and associated asymmetric keys, or the use of Kerberos. The need to deploy authentication information and its associated identities to network layer entities can be a significant obstacle to use of network security. This document explains the rationale for extending the Internet network security suite to enable use of IPsec security mechanisms without authentication. These extensions are intended to protect communication in a "better than nothing" (BTNS) fashion. The extensions may be used on their own (Stand Alone BTNS, or SAB), or may be useful in providing network layer security that can be authenticated by higher layers in the protocol stack, called Channel Bound BTNS (CBB). This document also explains situations in which use of SAB and CBB extensions are appropriate. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document is a product of the Better Than Nothing Security (BTNS) working group. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? The Document Shepherd for this document is Julien Laganier (BTNS WG co-chair). The Responsible Area Director is Sam Hartman (Security Area Director). From wang.yushun at gmail.com Wed May 23 14:27:18 2007 From: wang.yushun at gmail.com (Yu-Shun Wang) Date: Wed, 23 May 2007 14:27:18 -0700 Subject: [anonsec] AD Review: Probably and Applicability Statement In-Reply-To: References: <465148CF.9070207@gmail.com> Message-ID: <4654B1B6.9050209@gmail.com> Sam Hartman wrote: >>>>>> "Yu-Shun" == Yu-Shun Wang writes: <...> >>> I wonder if the working group has adequately reviewed section >>> 5.7. In particular do we actually have a strong consensus that >>> caching of BTNS credentials is inappropriate? We certainly have >>> a lot of issues to work through before we can recommend this >>> caching. But if there is no caching how is that leap of faith at >>> all? > > Yu-Shun> At our original draft draft, I left it as "?" (or TBD) We > Yu-Shun> can change it back to TBD. > > Yu-Shun> The text (as I remembered) deliberately does NOT take a > Yu-Shun> position on the debate of what LoF is between the two > Yu-Shun> mechanisms: accepting the unauth ID vs. caching it (and > Yu-Shun> treating it differently next time). We just explained > Yu-Shun> what the two mechanisms are and stated the status of our > Yu-Shun> understanding. I am personally neutral to this. It's the > Yu-Shun> WG's call. > > Yu-Shun> By the way, we (the authors) went through a lot of > Yu-Shun> discussion to keep the position neutral, stating the > Yu-Shun> issues involved and what will need to happen (at a very > Yu-Shun> high level) to make it work or secure. IIRC we didn't > Yu-Shun> shut the door so to speak. > > That's not how the section currently reads at all. The last sentence > tries to keep the door open but really does not interact well with > the table where you say that caching cannot be done in BTNS. Sure. I'll change the table to TBD then. Ok with the WG? > The section also does not discuss the problems with unauthenticated > credentials. IT says what extra work is needed but not really why. Let me see if I understand your concerns: (correct me if I am wrong) (1) the doc does not discuss the problems with unauth'ed credentials (2) the doc does not explain why extra work is needed My understanding is that SSH-style LoF does three things: (a) ask users if they want to accept unknown credentials (b) cache them if the users say "yes" (c) accept the cached credentials in the future w/out prompts This effectively "upgrades" the cached credentials to a higher level of trust in SSH. The position the authors agreed upon is that for SAB, you should not do that, especially (c). The problem is "... the credentials should not be cached because they remain unauthenticated, ..." IMO that is the problem, or at least the core of it. For CBB, it's less of a concern because you will need to do higher level auth anyways, just like SSH actually. I am not sure what other problems or reasons you have in mind other than "it's still unauthenticated, you probably should not trust it." That, to me, is the reason and problem. Things you listed below are additional work IF we want to go that route. To me that belongs to another doc. > Extra work includes: > * A Mechanism for user acceptance before caching > * How do you know when you are talking to the same peer > (mobility/address ownership issues) These sound like the SSH stuff listed above (a)-(c) plus the verification. The current text: " SSH-style credential caching for reuse with SAB can be added as a future extension to BTNS-IPsec; such work would need to provide warnings and checks on unauthenticated credentials in order to establish a level of assurance of authentication compared to SSH's "Leap of Faith." " While not in so much details, IMO provide a high level picture of your list, no? (I can of course just change the text to your list. But it's still not clear to me what else in the rationale part I missed regarding the tasks.) > * How do you support key rollover/what do you say about this I thought that's part of IKE SA rekeying? > IMHO, you're not done with this section. If the authors don't have > the experiense internally to complete this section then the WG needs > to provide that. Again (to the wg), text suggestion is most welcome. :-) >>> Section 6 rules mobility, nat and multihoming out of scope. >>> Please provide an argument that btns does not make issues >>> associated with nat and multihoming worse. IN particular think >>> about address selection for inner addresses with anonymous open >>> services and show that this problem is not worse in a BTNS >>> universe. > > Yu-Shun> I am no expert to all of those. Text suggestion? > > You need to get someone to do the engineering work first. I.E. I > think it may well be the case that BTNS creates problems in these > areas that need to be addressed. Someone in the WG actually needs to > work through these issues enough to figure out whether that's the > case. I simply provided requirements you'd need to meet if you want > to take the current direction. Fair enough. Other comments and texts from the WG? (I am in the process of moving. So apologize in advance of any delay on my part.) Thanks, yushun From mcr at sandelman.ca Thu May 24 07:56:30 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 24 May 2007 10:56:30 -0400 Subject: [anonsec] AD Review: Probably and Applicability Statement In-Reply-To: References: Message-ID: Sam Hartman wrote: > I wonder if the working group has adequately reviewed section 5.7. In > particular do we actually have a strong consensus that caching of BTNS > credentials is inappropriate? We certainly have a lot of issues to > work through before we can recommend this caching. > But if there is no caching how is that leap of faith at all? > > If there is such a consensus then Section 5.7 should be removed and a > section added to the applicability statement saying that leap of > faith/credential caching is out of scope. (re-reads 5.7) I think that we wish to retain it. btw, I think that s/SSH/implementations of the SecSH protocol/ there. 5.7 doesn't really tell me whether I'm allowed or encouraged to cache credentials. Remember that a ssh client gets to interact with the user, while the IPsec IKEv* usually does not. This is the point of the table, but perhaps that point is lost. Finally, the decision to cache the credentials for next time is something a compliant implementations could do as a "local matter". Where it matters is whether we have any mechanisms for invalidating the cache, or indicating that records should be purged. SSH started without that. It now has provisions to do that via a DNSSEC authenticated SSHFP record. > and multihoming worse. IN particular think about address selection > for inner addresses with anonymous open services and show that this > problem is not worse in a BTNS universe. Yes, I asked this question several times in person and on the list, and the consensus was that BTNS would not function with IPsec NAT-traversal, because we didn't know what to propose for the inside (CHILD_SA). From mcr at sandelman.ca Thu May 24 08:07:25 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 24 May 2007 11:07:25 -0400 Subject: [anonsec] question: ID payload in BTNS IKE negotiation In-Reply-To: <20070514165924.6713.SHINTA@sfc.wide.ad.jp> References: <20070513223149.66EE.SHINTA@sfc.wide.ad.jp> <20070514165924.6713.SHINTA@sfc.wide.ad.jp> Message-ID: mcr> My suggestion is that it should be IPV4/IPV6_ID of the host. Shinta Sugimoto wrote: > Hmm. This seems to me fine for static and/or single-homed environment, > but not ideal for mobile and/or multihomed environment (e.g. RFC 4555) > where IP address is not suitable for the purpose of identifying peers. > So, I think it would be better to use something different than IP > address for ID payload although I don't have good answer either at the > moment. Unless you propose to move during the lifetime of the connection, this concern does not apply. If you do move, then you establish a new SA. You use your new address. This is BTNS, you don't need long-term credential for PAD lookup. That's the whole point. If you are multihomed, and you might switch prefix, then you probably want MOBIKE, at which point, you might be able to propose multiple addresses. > Yes, that is true. And the use of identifier which is based on > IP address (ID_IPV4_ADDR/ID_IPV6_ADDR) will limit the applicability > of BTNS to static/single-homed environment as I mentioned above. I disagree strongly. It works just fine. >> 2. BTNS >> >> The IPsec processing model, IKE and IKEv2 are hereby modified as >> follows: >> >> o A new ID type is added, 'PUBLICKEY'; IDs of this type have public >> keys as values. This ID type is not used on the wire. > > I assume that the above sentence recommends not to use ID_PUBLICKEY as > an ID payload. If so, what is the reason behind? I see that it Because it's just an entry in the PAD. > (including ID_PUBLICKEY in ID payload) would simply be a duplication > because the public key is to be stored in CERT payload, but I believe > it still makes sense to use ID type which is independent from IP address > for ID payload. Any comments? You are now assuming that both ends know that they are doing BTNS. A number of the models assume that one end has strong authentication for the other end, in which case, it would expect something specific in the ID field. Note that each end may have independent notions of whether or not the peer will strongly authenticate it. As long as the public keys are present in a CERT payload, we do not have to tell the peers what mode of BTNS they are in. It may be that we will get strong authentication because the administrators of both peers have configured keys into their trusted store after checking fingerprints over the phone, in PGP signed email, etc. From julien.IETF at laposte.net Wed May 30 01:17:25 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Wed, 30 May 2007 10:17:25 +0200 Subject: [anonsec] test -- please ignore Message-ID: <200705301017.25457.julien.IETF@laposte.net> test -- please ignore From julien.IETF at laposte.net Wed May 30 04:23:15 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Wed, 30 May 2007 13:23:15 +0200 Subject: [anonsec] Consensus call on WG adoption of APIs drafts In-Reply-To: <18558.1178935860@marajade.sandelman.ca> References: <18558.1178935860@marajade.sandelman.ca> Message-ID: <200705301323.16643.julien.IETF@laposte.net> Folks, Michael has worked has worked on a revised abstract API, available at: While Miika has produced the corresponding C-bindings of this abstract API, available at: Hereby I'd like to call for WG adoption of both of these documents. If you agree, or disagree with adoption, please send an email saying so to the mailing list without changing the subject line before 2007-05-25. (OTOH please do change the subject line if you want to discuss contents of the documents themselves.) (If you have no time to read the documents, you might take a look at their respective presentations given during last meeting.) -- julien / BTNS co-chair From julien.IETF at laposte.net Thu May 31 01:41:48 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Thu, 31 May 2007 10:41:48 +0200 Subject: [anonsec] Consensus call on WG adoption of draft-komu-btns-api-01 In-Reply-To: <18558.1178935860@marajade.sandelman.ca> References: <18558.1178935860@marajade.sandelman.ca> Message-ID: <200705311041.49271.julien.IETF@laposte.net> Folks, Miika has worked on C-bindings for the abstract API (draft-komu-btns-api-01). Hereby I'd like to call for WG adoption of this document. If you agree, or disagree with adoption, please send an email saying so to the mailing list without changing the subject line before 2007-06-14. (OTOH please do change the subject line if you want to discuss contents of the documents themselves.) (If you have no time to read the documents, you might take a look at their respective presentations given during last meeting.) -- julien / BTNS co-chair From julien.IETF at laposte.net Thu May 31 01:41:44 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Thu, 31 May 2007 10:41:44 +0200 Subject: [anonsec] Consensus call on WG adoption draft-richardson-btns-abstract-api-00 In-Reply-To: <18558.1178935860@marajade.sandelman.ca> References: <18558.1178935860@marajade.sandelman.ca> Message-ID: <200705311041.45322.julien.IETF@laposte.net> Folks, Michael has worked on a revised abstract API, available at: Hereby I'd like to call for WG adoption of this document. If you agree, or disagree with adoption, please send an email saying so to the mailing list without changing the subject line before 2007-06-14. (OTOH please do change the subject line if you want to discuss contents of the documents themselves.) (If you have no time to read the documents, you might take a look at their respective presentations given during last meeting.) -- julien / BTNS co-chair From Nicolas.Williams at sun.com Thu May 31 10:41:53 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 31 May 2007 12:41:53 -0500 Subject: [anonsec] mailing list problems Message-ID: <20070531174153.GT27420@Sun.COM> Joe, Please make your filters smart enough to allow postings by subscribers or by senders who've posted before or remove the filters altogether. If you don't then I will ask the chair to create a btns at ietf.org list and move the WG discussion to it. (The chair may refuse to do that, of course.) Nico -- From simon at josefsson.org Thu May 31 08:52:07 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 31 May 2007 17:52:07 +0200 Subject: [anonsec] Consensus call on WG adoption of draft-komu-btns-api-01 In-Reply-To: <200705311041.49271.julien.IETF@laposte.net> (Julien Laganier's message of "Thu, 31 May 2007 10:41:48 +0200") References: <18558.1178935860@marajade.sandelman.ca> <200705311041.49271.julien.IETF@laposte.net> Message-ID: <87bqg1yorc.fsf@mocca.josefsson.org> I object to standardize any API that uses data types from a particular external implementation (in this case OpenSSL). The approach used in this document appear to require that every implementation of the document needs to #include OpenSSL headers, and possibly call OpenSSL functions (the implementation of the ipsec_openssl_to_channel_info is unclear to me). I believe that is clearly unacceptable for any Standards Track document. If this problem can be solved, by having a generic interface to input the necessary information needed from the TLS library, the document seems like a useful contribution to me. A suggestion for an improvement to the document would be to add a copyright license to the example code to make it possible to use the example in implementations. This often helps spread usage and leads to faster adoption of the API. See section 3 of draft-josefsson-free-standards-howto-00.txt. /Simon Julien Laganier writes: > Folks, > > Miika has worked on C-bindings for the abstract API > (draft-komu-btns-api-01). Hereby I'd like to call for > WG adoption of this document. If you agree, or > disagree with adoption, please send an email saying so > to the mailing list without changing the subject line > before 2007-06-14. (OTOH please do change the subject > line if you want to discuss contents of the documents > themselves.) > > (If you have no time to read the documents, you might > take a look at their respective presentations given > during last meeting.) > > -- julien / BTNS co-chair > _______________________________________________ From Nicolas.Williams at sun.com Thu May 31 10:06:52 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 31 May 2007 12:06:52 -0500 Subject: [anonsec] Consensus call on WG adoption draft-richardson-btns-abstract-api-00 In-Reply-To: <200705311041.45322.julien.IETF@laposte.net> References: <18558.1178935860@marajade.sandelman.ca> <200705311041.45322.julien.IETF@laposte.net> Message-ID: <20070531170651.GP27420@Sun.COM> On Thu, May 31, 2007 at 10:41:44AM +0200, Julien Laganier wrote: > Hereby I'd like to call for WG adoption of this > document. If you agree, or disagree with adoption, > please send an email saying so to the mailing list > without changing the subject line before 2007-06-14. I am in favor of adopting this document. From Nicolas.Williams at sun.com Thu May 31 10:07:30 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 31 May 2007 12:07:30 -0500 Subject: [anonsec] Consensus call on WG adoption of APIs drafts In-Reply-To: <200705301323.16643.julien.IETF@laposte.net> References: <18558.1178935860@marajade.sandelman.ca> <200705301323.16643.julien.IETF@laposte.net> Message-ID: <20070531170729.GQ27420@Sun.COM> On Wed, May 30, 2007 at 01:23:15PM +0200, Julien Laganier wrote: > Hereby I'd like to call for WG adoption of both of > these documents. If you agree, or disagree with > adoption, please send an email saying so to the > mailing list without changing the subject line before > 2007-05-25. (OTOH please do change the subject line if > you want to discuss contents of the documents > themselves.) I am in favor of adopting both documents.