From owner-ietf-kink@mail.vpnc.org Tue Apr 5 00:46:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16437 for ; Tue, 5 Apr 2005 00:46:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j354agEF000404; Mon, 4 Apr 2005 21:36:42 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j354agBp000403; Mon, 4 Apr 2005 21:36:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j354aeuG000396 for ; Mon, 4 Apr 2005 21:36:41 -0700 (PDT) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 6380F5E for ; Tue, 5 Apr 2005 13:36:39 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 4jzdzV; Tue, 5 Apr 2005 13:36:39 +0900 (JST) Date: Tue, 05 Apr 2005 13:37:14 +0900 Message-ID: <20050405133714RD%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: KINK issue list rev.6 User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi. I think that there were rough consensuses on solutions which have been proposed on the list, and remaining issues have been discussed and have directions of the fixes at the IETF-62 meeting. Please let me know if I've missed any issues which have no consensus at all or whose solutions are not summed up well. I'm pleased to provide any work I can do to make it go forward. I feel a few issues (on U2U/cross-realm) need to be rechecked when a revised draft is submitted. in discussion: 0 solution proposed: 0 waiting a revision: 41 closed: 2 --------------------------- total: 43 [**] Indicates an issue considered substantive. [-] Indicates an editorial issue. (2401bis) Indicates it depends on 2401 vs 2401bis. Category: Clarifications related to kcrypto =========================================== #8 CksumLen (section 5) (waiting a revision) Diagram indicates one octet for cksumlen, but the text (and kcrypto specifications) say it should be two. Proposed solutions: - Clarify that you mean the padding discussed in 5.1 (KINK Padding rules), not crypto-system padding. (Sam Hartman) - Use 2 octets for CksumLen field in accordance with kcrypto. See also: #9 #9 [**] etype does not directly indicate checksum type (section 5) (waiting a revision) a key's encryption type does not directly indicate a checksum type, it indicates an encryption(-with-integrity-protection) scheme, which does include a required-to-implement checksum type (Ken Raeburn) Proposed solutions are: - Use "required checksum mechanism" checksum type determined by the etype. - Use get_mic or verify_mic function to generate or verify the checksum. - Omit the checksum field before calculation. - The Length field is filled with the packet length without checksum and the CksumLen field is zeroed out before the calculation. - Move the Cksum field to the end of the message. (maybe without padding between the last payload and checksum?) (Message-ID: <20050131093509FD%kamada@nanohz.org>) #10 [**] Kerberos allows variable length checksum (section 5) (waiting a revision) I'd have to go back and check, but I don't think we require that a given checksum type have a fixed output size, so "leave X amount of space and fill it with zero for computing the checksum" is questionable too. (Ken Raeburn) Proposed solution: look at #9 #11 Kerberos checksum is not deterministic (section 5) (waiting a revision) The Kink description of how to verify a checksum assumes that Kerberos checksums are deterministic; this is not strictly required. (Sam Hartman) let kcrypto specify how to verify a checksum, as they're not required to be deterministic, so the "compute it again and compare" approach specified in section 5 is wrong (Ken Raeburn) Proposed solution: look at #9 #20 [**] KINK_ENCRYPT format (section 5.1.8) (waiting a revision) The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is vague. I think of using the output of raw encryption algorithms (i.e. E(confounder | plaintext | pad)) or using EncryptedData. treat "encryption with integrity protection" output as a whole, don't peek under the covers to find a "checksum" part you can throw away (Ken Raeburn) drop references to the initialization vector (Ken Raeburn) Please use the output of the kcrypto encrypt operation directly. Of most importance is to make sure that all kcrypto enctypes will work even if it is not possible to decompose the kcrypto checksum from the encrypted data. This probably means that in some cases you will have double checksums. You also need to deal with making sure you can determine the length of the plaintext. (Sam Hartman) Related thread: Message-Id: <20050204205737C.sakane@kame.net> Proposed solution: Use the output of the kcrypto encryption. #25 [**] prf (section 8) (waiting a revision) Section 8 says "prf is the same hash algorithm found in the session ticket's etype", but krb-wg-crypto-07 defines hash as unkeyed. Fortunately krb-wg-crypto-07 defines a PRF for each etype, so KINK should use this PRF. Use a prf from kcrypto, don't assume the checksum operations are deterministic hash functions (Ken Raeburn) Section 6.1 (the description of hash algorithm): This checksum may not be deterministic and is probably not appropriate for use in setting up a key. A PRF is provided, although depending on how the hash is used the PRF may or may not be a suitable replacement. There has been significant discussion within krb-wg on when the PRF is appropriate and when it is not. This discussion centered around key determination in pkinit. (Sam Hartman) Related thread: <20050210161443XN%kamada@nanohz.org> Proposed solution: - use RFC 3961 PRF (instead of "hash") to generate KEYMAT. (PRF is suitable for key generation for KINK.) #26 Key derivation (section 8) (waiting a revision) The key derivation seems inconsistent with the crypto framework document. (Sam Hartman) I don't understand what this section says well enough to determine whether it works with kcrypto. (Sam Hartman) Proposal: <20050221165123IJ%kamada@nanohz.org> #28 Key usage (waiting a revision) Usage of kink should specify the key usage numbers for kerberos encryption. (Sam Hartman) You can assign the numbers out of the space reserved for applications if principals used for kink will not be used for other purposes. If principals used for kink will be used for other purposes it is probably desirable to talk to Tom Yu and get a key usage number added to 1510ter. You'll also want to add the same key usage number to Kink to avoid a normative reference to 1510ter. (Sam Hartman, Message-ID: ) Related thread: <4208422C.5020905@miyazawa.org> Proposal: - Get 2 key usage numbers (for KINK_ENCRYPT and KINK Cksum) from 1510ter. (and defined them in the KINK draft to avoid waiting 1510ter as a normative reference.) Category: U2U (and cross-realm) issues ====================================== #3 [**] Choosing the right principal when U2U (waiting a revision) It seems like the server tells the client what principal to authenticate to, but this principal is not properly authorized. (Sam Hartman) Section 5.1.2: How do I authorize which service I'm talking to in the u2u case. I.E. how do I know what principals are authorized for a particular SPD entry? (Sam Hartman) Proposal: - The initiator should know the responder's principal name in the same way with non-U2U case. <20050225114411XP%kamada@nanohz.org> #19 [**] Cross-realm and U2U (section 4.2 and 5.1.5) (waiting a revision) Please Consider how this works in the cross-realm case. I.E. make sure you end up with the right ticket on the right side. I believe this text assumes that you need a ticket in a realm close to the client; I think that for things to work you actually need a realm close to the server. Work through the message flows and make sure the KDC doing the decryption actually has the necessary keys and then adjust the document if necessary so the right KDC is used. The document needs to clearly indicate what error code is used in the case when the responder cannot get a ticket because some cross-realm key is missing. In general we want it to be possible for an initiator to try several identities until the initiator finds the right one that has a shared key. (Sam Hartman, <20050129021939.1963F76C87@luminous.mit.edu>) Proposal: - Change GETTGT. (The initiator specified the responder's principal name. The responder returns a TGT for its own realm.) <20050225114411XP%kamada@nanohz.org> #7 [**] DPD: rebooting peers when U2U (section 4.4.2 and 4.5) (waiting a revision) [**] Discuss status message, rebooting peers and u2u. This looks a lot like the IKE case where you lose all cryptographic context to me. (Sam Hartman) I don't understand what you want here. Are you saying that this doesn't work in the u-u case? I don't understand what u-u has to do with anything here. (Michael Thomas) OK. I was unclear . When sending a status message, what happens if the peer has gotten a new TGT? How do I realize I need to use this TGT rather than the one I have? (Sam Hartman) Proposal: <20050308141232O.sakane@kame.net> - When the responder can't decrypt a U2U KINK_AP_REQ, it returns KINK_TGT_REP with a new TGT. - Then the initiator retry the command with a new service ticket retrieved using the new TGT. - This sequence doesn't directly define how to detect a dead U2U peer, but just define how to recover from the situation that the responder has changed its TGT. - After recovery, the initiator can see whether the responder has been dead or not using the usual DPD method. #2 U2U (section 3, 4.2, and 5.1.2) (waiting a revision) See also: #3, #19, #44, and #7 I think we need to look at how u2u works at various parts of the protocol. In particular I'm concerned about choosing the right u2u principal, dealing with cross-realm u2u and dealing with recovering from reboots. We should confirm all these work out. (Sam Hartman) # choosing the right u2u is discuessed in #3. # cross-realm u2u is discussed in #19. # how to know and get new TGT when peer reboots is discussed in #7 More examination of user-to-user case, especially situations where it might *not* be two PKINIT clients, which section 3 says is possible. (Ken Raeburn) In the user-to-user case with TGTs, I think the KINK draft may be over-specifying things that should be dealt with at the Kerberos level. If things are underspecified in Kerberos Clarifications, let's deal with that. (Ken Raeburn) Related thread: <20050307165305VZ%kamada@nanohz.org> and <20050225114411XP%kamada@nanohz.org> (1) what principal to use -- needs to be in PAD (2) whether to use U2U -- PAD, or learning from remote side. you can use KDC errors for optimization, but can't depend on them. (3) in cross-realm U2U, in what realm do you rendesvous? -- target (responder's) realm Review U2U after the next version of the document is published. (@IETF62) #44 [**] How to determine whether the initiator can get a TGT (waiting a revision) Section 4.2: How will the initiator determine whether it will be able to get a TGT? I think policy considerations of when to use u2u and authorization considerations of what u2u principals are authorized are underspecified in the draft. (Sam Hartman) Proposal: - when to use u2u is the Kerberos matter. - what u2u principal to use: initiator knows the responder's principal name in advance and specify it in the GETTGT. See <20050225114411XP%kamada@nanohz.org> for more detailed proposal. Category: Other Kerberos matters ================================ #17 [**] Checksum when KRB-ERROR occured (section 5.1.4 and 7.1) (waiting a revision) Section 7.1 says the checksum in the KRB-ERROR message is not used, but section 5.1.4 says that KINK implementation MUST make use of keyed Kerberos errors. But KRB-ERROR does not have checksum in it (at least with RFC 1510 or kerberos-clarifications). Proposals: Use KINK checksum instead of signed KRB-ERROR of 1510ter. Replace following paragraph of section 5.1.4 KINK implementations MUST make use of keyed Kerberos errors when the appropriate service key is available as specified in [KRBREVS]. In particular, clock skew errors MUST be integrity protected. For unauthenticated Kerberos errors, the receiver MAY choose to act on them, but SHOULD take precautions against make-work kinds of attacks. with KINK implementations MUST make use of a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate service key is available. Drop reference to krb-error checksum from section 7.1. (Sam Hartman) defined in the following sections. The checksum in the KRB-ERROR message is not used, since the KINK header already contains a check- sum field. #18 [**] Kerberos error type limitations (section 5.1.4) (waiting a revision) Why should a sender send only those errors? I'm mostly asking for an explanation to be given to me or to be added to the document rather than liberalization of the requirement. (Sam Hartman) Related thread: Message-Id: <20050204202941G.sakane@kame.net> Proposed solution: - Remove the limitation. #12 [**] Subsession keys (section 5 and 8) (waiting a revision) Are subsession keys ignored? (Ken Raeburn) The description of the checksum says that the session key of the ticket is used. That's a way to do it, but the working group should explain why it has chosen to ignore the subsession key. (Sam Hartman) Related thread: Message-ID: <20050127171703FZ%kamada@nanohz.org> Michael> more entropy from subsession keys buy us almost nothing (ISAKMP NONCE is enough). There are people who have been writing to *this* spec for several years now. And old mail: <15190.63952.167857.646848@thomasm-u1.cisco.com> Bill> The session key is long-lived. (but it's not really all that different from a per-exchange nonce.) Sam> Being the same as everyone else is preferred if we have no reason. No need to change the behavior. The nonce is sufficient to make it not necessary to use subkeys. "MUST not send. SHOULD ignore on receive." ? (@IETF62) Category: Handshake clarifications ================================== #5 When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3) (waiting a revision) Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the nonce should be used. If the circumstances they're describing are different, that's okay, but if so, I missed it on first reading. (Ken Raeburn) They are talking the same situation and the requirement levels should be aligned. I think SHOULD is appropriate because non-returning responder's nonce does not break interoperabilities. (Message-ID: <20050127171441FF%kamada@nanohz.org>) If the initiator receives a responder's nonce, she MUST use it in the KEYMAT calculation. I think it is also editorial issue. anyway, the behavior depends on condition. if a responder does not agree with the initiator's proposal, AND if the responder wants to continue the transaction, then the responder MUST send back a message with ACK request bit, and MAY contain a nonce. There is a case when the responder wants to use same KEYMAT of the initiator, but just doesn't want to use the initiator's proposal. It is not always required to add a nonce. (Message-Id: <20050204200406K.sakane@kame.net>) Proposal: - The responer's nonce in 3-way handshake is SHOULD. - When the responder request ACK (sakane-san's comment) is discussed in #45. #45 When to add SAs and which SAs to add in 3-way handshake (waiting a revision) derived from #5 and #37, and related to #23. When does the responder require ACK? - disagreeing on the proposal - doing KE (dispite accepting or rejecting?) - agreeing with the parameters but want to add NONCE (Is this allowed in KINK?) When to add (and remove if necessary) SAs? - usual optimistic approach - (non-KE) 3-way These two are already described in the current draft. - KE 3-way Proposal: - describe that the KE payload requires ACK. - describe that the initiator defer the installation of the inbound SA until it receives REPLY message, when using KE payloads. (because the initiator can't calculate KEYMAT before that.) #37 [**] Difference between IKE and KINK on CREATE command (section 4.3) (waiting a revision) IN addition, any differences between how this works and how IKE would set up the same SA need to be called out. It is fine for there to be differences, but I want to make sure the working group explicitly decided the differences are a good thing. I'm somewhat concerned that 4.3 is not specific enough to describe exactly what key gets set up. I.E. I'm concerned it may not be detailed enough for interoperable implementations. (Sam Hartman) - What keys are used for the resulting SA on the each side? (Sam Hartman, Message-ID: ) Related thread: <20050204170451BM%kamada@nanohz.org> and <20050221115212RM%kamada@nanohz.org>. To be revisted after rewriting section 8. (#26 is the same issue?) hartmans: I think we can close #37 if there is consensus on the new text for section 8 derek: Assume 37 is closed. Note that sam will have to read/review ike. (@IETF62) - (closed) Doesn't the timing when to add in/out SAs conflict with IKE? (Sam Hartman, Message-ID: ) Related thread: Message-ID: <20050204170454BO%kamada@nanohz.org> There is no objection. - (closed) How about when to add SAs and which SAs to add when 3-way. (Message-ID: <20050204170454BO%kamada@nanohz.org>) --> moved to #45 #4 [**](2401bis) CREATE command from the aspect of 2401bis (section 4.3) (closed) I need explicit review from the IPsec reviewer of this section to make sure it is compatible with 2401bis. Closed: being discussed with #37 Category: Error handling ======================== #1 [**] Versioning (waiting a revision) what happens when a receiver receives a major or minor version of the kink or qm that is inconsistent with this document? What about unknown payload types? (Sam Hartman) QM version is discussed in section 12 (Forward Compatibility Considerations). Related thread: Message-Id: <20050202105420R.sakane@kame.net> Proposed solution: - KINK version remove the minor version and KINK_INVMIN error code. - QM versoin already specified in section 12. - KINK payload type return error (KINK_PROTOERR) - ISAKMP payload type return error (ISAKMP INVALID-PAYLOAD-TYPE) (describe each Notify type usage like ikev2 spec.) Specify the behavior when the error is not authenticated in the Security Consideration section. (<20050202105420R.sakane@kame.net>) #23 KE interoperability (section 6.8) (waiting a revision) What happens if a peer that implements the KE payloads communicates with a peer that does not. Specify the behavior in sufficient detail to guarantee interoperability. (Sam Hartman) Releated thread: Message-Id: <20050204213547M.sakane@kame.net> Proposal: - When the responder does not like the KE handling, the responder just reply an ISAKMP error (NO-PROPOSAL-CHOSEN or INVALID-KEY-INFORMATION.) The initiator must proceed the next step properly. <20050228082837W.sakane@kame.net> #31 behavior on KINK_ERROR (waiting a revision) In implementor's point of view, I'd like to see initiator's behavior in receiving KINK_ERROR to be defined. For example: - When KINK_OK is received, initiator MAY act as if the KINK_ERROR payload was not included in the messaged. - When KINK_BADQMVERS is received and the Cksum is verified, initiator MAY retry in other Quick Mode version. - When one of other error codes is received and the Cksum is verified, initiator SHOULD abort the negotiation. when does the responder generate these errors? Proposal: <42198868.7080309@miyazawa.org> - Add simple description of each error codes. + when these errors are generated by responders. + how to act on these errors. Category: IANA considerations ============================= #33 [-] IANA considerations (section 11) (waiting a revision) I think the correct terminology is "port number", not "port", and they're "assigned", not "created". This section says no new registries are required in the first paragraph, and the third one specifies that IANA must create one (but without the associated procedural data that is required nowadays). Are the KINK payload types and ISAKMP payload types actually ever used in the same field? If not, I don't think they need to come out of the same registry. (Ken Raeburn) Needs work. You may want to stop by tthe IANA office hours and ask them for advice. They are generally quite good at working with authors to figure out how things need to be specified. (Sam Hartman) See BCP 26 (RFC 2434). Related thread: <20050307084029U.sakane@kame.net> Proposal: <20050309225109Q.sakane@kame.net> 1) from the current docuemnt, the folloing codes are IANA matter. - KINK message type - KINK payload type - KINK error code - KINK port number 2) We have to register - KINK message type - KINK payload type - KINK error code Category: Other clarifications ============================== #16 EPOCH (section 5.1.2) (waiting a revision) Perhaps you need a description of the time stamp? I recall there being such a description in draft-housley-binarytime-xx. (Sam Hartman) Related thread: Message-ID: <20050210154348XQ%kamada@nanohz.org> Proposal: - Just says EPOCH MUST NOT reused in a short period, and leave the format to the implementations. If the draft uses POSIX time, we'll need to describe the semantics of the value like draft-housley-binarytime-xx or refer to POSIX. #22 Kerberos PFS (section 6.8) (waiting a revision) Sec 6.8: "Kerberos in general does not provide PFS so it is somewhat questionable whether a system which is heavily relying on Kerberos benefits from PFS." First, that sounds like it might be Security Considerations material. Second, I don't follow; explain please? (Ken Raeburn) Related thread: Message-Id: <20050204211105O.sakane@kame.net> - (Current) Kerberos doesn't provide PFS. - KINK optionally provides PFS. - KINK PFS has benefits but is not mandatory because of the computational cost. so editorial fix (or even removing this sentence) would be enough. Proposal: - Rewrite the section 6.8 according to the above points. (The AD is ok not to mandate PFS if the WG wants to go that route.) #27 (2401bis) SPD Considerations (section 10.1) (waiting a revision) This should not go in the security considartions section. It is really more about IPsec architectural considerations than security considerations. This text needs to take into account 2401bis. In particular it needs to be properly split between SPD considerations and PAD considerations. (Sam Hartman) Related thread: Message-ID: <420865DD.1040507@miyazawa.org> Proposal: - This section does not describe security issues, so move it to the outside of the security considerations section. - If KINK refers to 2401bis, almost of this section is related to PAD rather than SPD, so need to clarify SPD/PAD issues. #29 (2401bis) Rekeying (section 4.4.1) (waiting a revision) section 4.4.1: Please make sure this discussion is aligned with 2401bis. I think it may change small details but they seem to have adopted much of the same strategy kink uses. The area wher I believe they speak to this issue is when you should rekey (timers etc). (Sam Hartman) Related thread: <42119FC4.8020607@miyazawa.org> Proposed solution: - clarify with the 2410bis words + "hard lifetime minus rekey margin" --> soft lifetime. + randomize soft lifetime. #13 [**] Replay protection (section 5) (closed) The document claims that the transaction id is not used for replay detection because Kerberos provides that. How is that true? The authenticator is protected against replays but how is the rest of the message bound to that specific authenticator instead of to a session key of a ticket? (Sam Hartman) Closed: not a issue. (Message-ID: ) #30 (2401bis) IKEv2 (waiting a revision) Should we adopt IKEv2? If we should... - IKEv2 does not have DOI, so how to handle the DOI field in the KINK packet header should be described. - Use TS (Traffic Selector) instead of ID (Identification). - KEYMAT calculation is changed. - How to handle REKEY_SA Notify type. - IKEv2 doesn't negotiate the SA lifetime. Rekeying in KINK is up to the initiator. Therefore, the lifetime of the responder can happen to be shorter, and the responder has no way to rekey. Related threads: Message-ID: Message-ID: <20050120111553S.sakane@kame.net> Proposal: - We will describe things in 2401bis way, but conforming to IKEv2 is not important. <20050222195329O.sakane@kame.net> Category: Editorial =================== #6 Half open (section 4.4) (waiting a revision) IPsec does not allow half-open security associations any more as far as I can tell in 2401bis. So it's not just for simplicity, but for model conformance. (Sam Hartman) Proposed solution: - remove the phrase "for simplicity". (Message-ID: ) #14 [-] Reserved (15 bits) -- Reserved and must be zero (section 5) (waiting a revision) must be zero on send, must be ignored by receiver. #15 [**] How to get the principal name of KINK service (section 5.1.2) (waiting a revision) How do I discover the FQDN of my remote peer? SPD entries are configured in terms of IP addresses. If you want to store an identity in the PAD, why not store a principal instead of a hostname. I interpreted the text as a naming convention, not how a implementation get a peer's principal name. So I think it is an implementation issue whether a principal name is generated from a FQDN or got directly from the PAD. (KAMADA Ken'ichi, <20050131095154FY%kamada@nanohz.org>) Proposal: - Clarify the descriptions so as to avoid misunderstandings that the principal names must be generated from FQDNs. #21 Next Payload in KINK_ENCRYPT (section 5.1.8) (waiting a revision) Text should probably indacte that next payload must be none. Proposed solution: The section 5.1 describes it, however it would be better to describe explicitly so. reader does not has trouble even if the text is described repeatedly. (Message-Id: <20050204210401T.sakane@kame.net>) #24 MUST or SHOULD in clock skew processing (section 7.1) (waiting a revision) The time difference MUST be computed and SHOULD be stored and used? Why the different requirement levels? (And is this sort of thing in the domain of KINK or Kerberos?) (Ken Raeburn) Related thread: Message-ID: <4202FB85.6080406@miyazawa.org> Proposal: - Just an editorial fix. + Use SHOULD in the descriptoin of the initiator processing. + The description itself should remain untouched. #32 [-] I-D nits (waiting a revision) Review the I-D nits and RFC authors docs. I spotted a lot of mechanical things (number of lines per page; avoid hyphenation; use ragged right margin; need two spaces after sentence-ending period; fix page numbers in table of contents; add section numbers to TOC) most of which I think are specified in one of those documents. (Ken Raeburn) the document needs to meet all the ID nits when it is submitted. (Sam Hartman) #35 [-] References (waiting a revision) The reference to [PKCROSS] is unnecessary, and only happens once, in the introduction. I'd suggest dropping it. That's one less unpublished I-D in the references section. (Ken Raeburn) [KRBREVS] is referenced but not listed in the references section. (Ken Raeburn) Sec 5.1.7, next to last paragraph on page 21, is "IKE" (the protocol) fuzzy about use of different SAs, or is it "[IKE]" (the document)? (Ken Raeburn) Section 1: Remove the reference to pkcross or cite something outside the IETF. It's an expired ID without and active editor. (Sam Hartman) Section 1: Add an informative reference to IKE. (Sam Hartman) Section 2: Cite a reference for DER. (Sam Hartman) Section 5: DOI Cite a specific registry please. IANA registries are typically named, and a URL reference would probably be appropriate. #36 [-] Typos (waiting a revision) 4.4.2. Dead Peer Detection In the fourth paragraph, "loose" is to be "lose". 5.1 KINK Payloads In the first item, the length of the Next Payload should be one octet instead of two. 5.1.1. KINK Padding Rules In the second item, "other other" is to be "other". 5.1.1. KINK Padding Rules The first item in the list should end with a period like the others. (Ken Raeburn) 5.1.5. KINK_TGT_REQ Payload In the third item, "krbtgt/REALM/@REALM" is to be "krbtgt/REALM@REALM". 5.1.6. KINK_TGT_REP Payload In the caption of Figure 13, "KINK_TGT_REQ" is to be "KINK_TGT_REP". 7.3. CREATE "IPspec" is to be "IPsec". 7.5. STATUS In the last paragraph, "REPLY KINK Header" should be in one line. In the last paragraph, "[KRB_ERROR]" is to be "[KINK_ERROR]". overall: "'s" is used in some places where I'd use "s" for a plural form. #38 [-] Terminology (waiting a revision) Section 2 and 10.1. Kerberos is now using the term user-user rather than user-to-user. (Sam Hartman) Section 2. Principals are not either client or service principals; they can and often do fill both roles. (Sam Hartman) #40 [-] Wording (waiting a revision) Section 2, last paragraph. "Between" is generally non-directional, but in this case, a direction seems to be intended to be inferred; try "from...to" instead. (Ken Raeburn) #41 [-] Wording in section 3, Protocol Overview (waiting a revision) Section 3, English usage/grammar problems with the first two paragraphs. (Sam Hartman) Section 3. which allows a final acknowledgment message when the respondent needs a full three-way handshake. This is only needed when the optimistic keying route is not taken, though it is expected that that will not be the norm. KINK also provides rekeying and dead peer detection as What is expected not to be the norm? Please reword. (Sam Hartman) #42 [-] Wording (waiting a revision) Section 4.3, discussing attributes, mixes singular and plural indications. The word "lone" appears to be popular with the author, too. :-) (Ken Raeburn) #43 [-] Wording (waiting a revision) Sec 8: "By optional, it is meant..." is badly worded. (Ken Raeburn) -- KAMADA Ken'ichi From alborad@emailaccount.com Wed Apr 6 17:34:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06763 for ; Wed, 6 Apr 2005 17:34:47 -0400 (EDT) Received: from user-0cdvnec.cable.mindspring.com ([24.223.221.204]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJIJ9-0007lJ-Tf for kink-archive@ietf.org; Wed, 06 Apr 2005 17:43:33 -0400 Received: from coop-jcoppens.com (EHLO ogress.jcoppens.com) by adhere.jcoppens.com with SMTP; Thu, 07 Apr 2005 00:28:22 +0200 Date: Thu, 07 Apr 2005 00:25:22 +0200 From: "Madeleine Horner" To: ixoyiaqsmesbdmrckpc@ietf.org Cc: j@ietf.org, jaime.hope@ietf.org, jana.mccormick@ietf.org, jarvis.bonilla@ietf.org, jeff.ayers@ietf.org, jjltcnsis-admin@ietf.org, jmunoz@ietf.org, juliek@ietf.org, jxknerouting-discussion-admin@ietf.org, kink-archive@ietf.org Subject: You've been selected for a low rate Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [934], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 20.1 (++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Rhoda Villarreal to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From riccard@mailAccount.com Wed Apr 6 17:35:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06885 for ; Wed, 6 Apr 2005 17:35:51 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJIKB-0007ne-Lx for kink-archive@ietf.org; Wed, 06 Apr 2005 17:44:36 -0400 Received: from h-68-166-198-180.nycmny83.covad.net ([68.166.198.180]) by mx2.foretec.com with smtp (Exim 4.24) id 1DJIBh-00014T-38 for kink-archive@ietf.org; Wed, 06 Apr 2005 17:35:49 -0400 Authentication-Results: bernard.es from=premium.rump.es; domainkeys=neutral (no sig) X-Originating-IP: [90.102.0.48] Received: from premium.jettison.es (EHLO premium.madcap.es) by premium.stewart.es with SMTP; Wed, 06 Apr 2005 21:33:32 -0100 Date: Wed, 06 Apr 2005 16:30:32 -0600 From: "Tristan Powell" To: ixoyiaqsmesbdmrckpc@ietf.org Cc: j@ietf.org, jaime.hope@ietf.org, jana.mccormick@ietf.org, jarvis.bonilla@ietf.org, jeff.ayers@ietf.org, jjltcnsis-admin@ietf.org, jmunoz@ietf.org, juliek@ietf.org, jxknerouting-discussion-admin@ietf.org, kink-archive@ietf.org, kml@ietf.org, knrhqrddp-admin@ietf.org, kontaktlens@ietf.org, kvylxmanet-admin@ietf.org Subject: Lowest rate approval Message-ID: <111641.4556.riccard@mailAccount.com> X-Mailer: Kana Connect 6 X-Spam-Score: 17.5 (+++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Tanisha Palacios to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From engt@mailAccount.com Wed Apr 6 17:39:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07182 for ; Wed, 6 Apr 2005 17:39:18 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJINW-0007sX-W5 for kink-archive@ietf.org; Wed, 06 Apr 2005 17:48:04 -0400 Received: from c-67-163-84-150.hsd1.il.comcast.net ([67.163.84.150]) by mx2.foretec.com with smtp (Exim 4.24) id 1DJIF3-0001AJ-Ch for kink-archive@ietf.org; Wed, 06 Apr 2005 17:39:17 -0400 Received: from completion.diabase-cornell.com (HELO clothesmen.com 66.5.168.98) by linen.com with EMQP; Wed, 06 Apr 2005 16:26:45 -0600 Date: Wed, 06 Apr 2005 18:26:45 -0400 From: "Melissa Herrera" Message-Id: To: jxknerouting-discussion-admin@ietf.org Cc: kink-archive@ietf.org, kml@ietf.org, knrhqrddp-admin@ietf.org, kontaktlens@ietf.org, kvylxmanet-admin@ietf.org Subject: Pre-approved Application #MLJZV949 X-Mailer: CompuServe 7.0 X-Spam-Score: 2.4 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Casandra Chin to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From politg@emailaccount.com Fri Apr 8 06:38:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01466 for ; Fri, 8 Apr 2005 06:38:42 -0400 (EDT) Received: from 82-34-170-139.cable.ubr03.maid.blueyonder.co.uk ([82.34.170.139]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJr1a-0004ut-RT for kink-archive@ietf.org; Fri, 08 Apr 2005 06:47:47 -0400 Authentication-Results: blackfeet.es from=premium.sanitarium.es; domainkeys=neutral (no sig) X-Originating-IP: [96.112.166.148] Received: from premium.crankcase.es (EHLO premium.compound.es) by premium.dystrophy.es with SMTP; Fri, 08 Apr 2005 16:34:03 +0500 Date: Fri, 08 Apr 2005 16:32:03 +0500 From: "Selena Bernard" To: juliek@ietf.org Cc: jxknerouting-discussion-admin@ietf.org, kink-archive@ietf.org, kml@ietf.org, knrhqrddp-admin@ietf.org, kontaktlens@ietf.org, kvylxmanet-admin@ietf.org Subject: Notification: We offer low rates Message-ID: <113041.6271.politg@emailaccount.com> X-Mailer: Kana Connect 6 X-Spam-Score: 6.9 (++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Eugenio Calhoun to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From coomb@didamail.com Fri Apr 8 06:42:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01800 for ; Fri, 8 Apr 2005 06:42:45 -0400 (EDT) Received: from [221.159.62.100] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJr5Y-00055U-Vr for kink-archive@ietf.org; Fri, 08 Apr 2005 06:51:50 -0400 Received: from centric-jcoppens.com (EHLO champ.jcoppens.com) by woe.jcoppens.com with SMTP; Fri, 08 Apr 2005 15:37:33 +0400 Date: Fri, 08 Apr 2005 09:39:33 -0200 From: "Lazaro Lynn" To: ixoyiaqsmesbdmrckpc@ietf.org Cc: j@ietf.org, jaime.hope@ietf.org, jana.mccormick@ietf.org, jarvis.bonilla@ietf.org, jeff.ayers@ietf.org, jjltcnsis-admin@ietf.org, jmunoz@ietf.org, juliek@ietf.org, jxknerouting-discussion-admin@ietf.org, kink-archive@ietf.org, kml@ietf.org, knrhqrddp-admin@ietf.org Subject: Rates fixed Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [567], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 9.9 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Myrtle Duvall to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From adorner@didamail.com Sun Apr 10 05:09:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04541 for ; Sun, 10 Apr 2005 05:09:58 -0400 (EDT) Received: from [210.180.20.169] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKYbF-0007xk-OP for kink-archive@ietf.org; Sun, 10 Apr 2005 05:19:28 -0400 Received: from emanate-jcoppens.com (EHLO catalina.jcoppens.com) by bibb.jcoppens.com with SMTP; Sun, 10 Apr 2005 13:05:10 +0300 Date: Sun, 10 Apr 2005 09:04:10 -0100 From: "Mario Boyd" To: jxknerouting-discussion-admin@ietf.org Cc: kink-archive@ietf.org, kml@ietf.org, knrhqrddp-admin@ietf.org, kontaktlens@ietf.org, kvylxmanet-admin@ietf.org Subject: Lowest rates in 45 years Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [920], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 15.4 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Felipe Boucher to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From legge@mailAccount.com Mon Apr 11 13:04:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29819 for ; Mon, 11 Apr 2005 13:04:37 -0400 (EDT) Received: from 81-202-128-63.user.ono.com ([81.202.128.63]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DL2UP-0006Zt-UA for kink-archive@ietf.org; Mon, 11 Apr 2005 13:14:24 -0400 X-Apparently-To: ixoyiaqsmesbdmrckpc@ietf.org X-Sieve: CMU Sieve 2.2 Received: from wharves.crew.pochta.ru ([unix socket]) by crockett.artifact.pochta.ru (Cyrus v2.2.3) with LMTPA; Mon, 11 Apr 2005 22:52:47 +0500 Date: Mon, 11 Apr 2005 20:51:47 +0300 From: "Ava Coffman" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: ixoyiaqsmesbdmrckpc@ietf.org Cc: j@ietf.org, jaime.hope@ietf.org, jana.mccormick@ietf.org, jarvis.bonilla@ietf.org, jeff.ayers@ietf.org, jjltcnsis-admin@ietf.org, jmunoz@ietf.org, juliek@ietf.org, jxknerouting-discussion-admin@ietf.org, kink-archive@ietf.org, kml@ietf.org, knrhqrddp-admin@ietf.org Subject: Pre-approved Application #TPKVYV440 X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 9.7 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mrg-now-yes.com/sign.asp Best Regards, Antwan Wiseman to be remov(ed: http://www.mrg-now-yes.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From maritsa@emailaccount.com Tue Apr 12 21:11:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01771 for ; Tue, 12 Apr 2005 21:11:17 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLWZC-0006Ck-FF for kink-archive@ietf.org; Tue, 12 Apr 2005 21:21:20 -0400 Received: from [220.127.226.157] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DLWPU-0004b1-4W for kink-archive@ietf.org; Tue, 12 Apr 2005 21:11:16 -0400 Authentication-Results: busboy.es from=premium.windbag.es; domainkeys=neutral (no sig) X-Originating-IP: [148.162.20.168] Received: from premium.dalhousie.es (EHLO premium.defuse.es) by premium.java.es with SMTP; Tue, 12 Apr 2005 19:08:12 -0700 Date: Wed, 13 Apr 2005 01:13:12 -0100 From: "Alma Hale" To: jxknerouting-discussion-admin@ietf.org Cc: kink-archive@ietf.org, kml@ietf.org, knrhqrddp-admin@ietf.org, kontaktlens@ietf.org, kvylxmanet-admin@ietf.org Subject: Save hundreds every month on low rates Message-ID: <119941.8029.maritsa@emailaccount.com> X-Mailer: Kana Connect 6 X-Spam-Score: 19.6 (+++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mrg-now-yes.com/sign.asp Best Regards, Garland Oakley to be remov(ed: http://www.mrg-now-yes.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From baskas@doramail.com Thu Apr 14 16:12:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19789 for ; Thu, 14 Apr 2005 16:12:25 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMArS-00088d-8V for kink-archive@ietf.org; Thu, 14 Apr 2005 16:22:51 -0400 Received: from p4050-ipad31fukuokachu.fukuoka.ocn.ne.jp ([220.107.75.50]) by mx2.foretec.com with smtp (Exim 4.24) id 1DMAhM-0002Kj-NA for kink-archive@ietf.org; Thu, 14 Apr 2005 16:12:25 -0400 X-Apparently-To: juliek@ietf.org X-Sieve: CMU Sieve 2.2 Received: from cotton.prostrate.pochta.ru ([unix socket]) by fade.hanover.pochta.ru (Cyrus v2.2.6) with LMTPA; Fri, 15 Apr 2005 01:06:15 +0400 Date: Thu, 14 Apr 2005 20:06:15 -0100 From: "Ebony Reynolds" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: juliek@ietf.org Cc: jxknerouting-discussion-admin@ietf.org, kink-archive@ietf.org, kml@ietf.org, knrhqrddp-admin@ietf.org, kontaktlens@ietf.org, kvylxmanet-admin@ietf.org Subject: High rates? Not with us! low fixed rate X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mrg-now-yes.com/sign.asp Best Regards, Deann Simmons to be remov(ed: http://www.mrg-now-yes.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From erges@didamail.com Fri Apr 15 08:17:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24168 for ; Fri, 15 Apr 2005 08:17:04 -0400 (EDT) Received: from [221.159.30.20] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMPv5-0003bW-3w for kink-archive@ietf.org; Fri, 15 Apr 2005 08:27:37 -0400 Received: from fruit-jcoppens.com (EHLO ledge.jcoppens.com) by acropolis.jcoppens.com with SMTP; Fri, 15 Apr 2005 11:12:51 -0200 Date: Fri, 15 Apr 2005 11:15:51 -0200 From: "Jan Crockett" To: ixoyiaqsmesbdmrckpc@ietf.org Cc: j@ietf.org, jaime.hope@ietf.org, jana.mccormick@ietf.org, jarvis.bonilla@ietf.org, jeff.ayers@ietf.org, jjltcnsis-admin@ietf.org, jmunoz@ietf.org, juliek@ietf.org, jxknerouting-discussion-admin@ietf.org, kink-archive@ietf.org, kml@ietf.org, knrhqrddp-admin@ietf.org Subject: Pre-approved Application #IWFV439 Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [670], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 7.6 (+++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.n0wwewillsave.com/sign.asp Best Regards, Iris Medeiros to be remov(ed: http://www.n0wwewillsave.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From owner-ietf-kink@mail.vpnc.org Fri Apr 15 11:23:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08925 for ; Fri, 15 Apr 2005 11:23:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FFJxBf081988; Fri, 15 Apr 2005 08:19:59 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FFJxSE081987; Fri, 15 Apr 2005 08:19:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from p62e727.kagwnt01.ap.so-net.ne.jp (p62e727.kagwnt01.ap.so-net.ne.jp [219.98.231.39]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3FFJmKQ081917; Fri, 15 Apr 2005 08:19:51 -0700 (PDT) (envelope-from ASCMCDGALSN@motorcadegm.com) Received: from unknown (HELO speakeasy.net) by speakeasy.net with DES-FWM3-SHA encrypted SMTP for ; Fri, 15 Apr 2005 20:16:22 +0400 Message-Id: Date: Fri, 15 Apr 2005 14:14:22 -0200 From: "Rocco" To: Subject: save with us Tommy Reply-To: MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Swiss pharmacy online warehouse

Valium $69, Levitra $69, Cialis $89
Viagra $69, Tramadol $69, Ambien $109
Phentermine $69, Xanax $99, Soma $59

With each purchase you get:

Home delivery.
Total confidentiality.
F.D.A ApprovedDrugs.


















you skye me barge me you aborigine me chlorinate me you thomistic me u me you bater me opine me you shod me rodeo me you depressible me school me you bing me camino me quit From cooter@didamail.com Fri Apr 15 17:42:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00333; Fri, 15 Apr 2005 17:42:15 -0400 (EDT) Received: from [218.152.207.73] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMYkA-0003S4-8a; Fri, 15 Apr 2005 17:52:55 -0400 X-Apparently-To: jjltcnsis-admin@ietf.org X-Sieve: CMU Sieve 2.2 Received: from thespian.define.pochta.ru ([unix socket]) by gape.is.pochta.ru (Cyrus v2.2.4) with LMTPA; Fri, 15 Apr 2005 15:37:44 -0700 Date: Fri, 15 Apr 2005 18:36:44 -0400 From: "Wallace Villarreal" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: jjltcnsis-admin@ietf.org Cc: jmunoz@ietf.org, juliek@ietf.org, jxknerouting-discussion-admin@ietf.org, kink-archive@ietf.org, kml@ietf.org, knrhqrddp-admin@ietf.org, kontaktlens@ietf.org, kvylxmanet-admin@ietf.org, l2tpext@ietf.org, l2tpext-admin@ietf.org, l2tpext-archive@ietf.org, l2tpext-web-archive@ietf.org Subject: Instant low rates X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 17.7 (+++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.n0wwewillsave.com/sign.asp Best Regards, Jeremy Poe to be remov(ed: http://www.n0wwewillsave.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s.