From ietf@augustcellars.com Thu Dec 5 10:54:55 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E421AE143 for ; Thu, 5 Dec 2013 10:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOcB8xiXOtEr for ; Thu, 5 Dec 2013 10:54:52 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7631AE142 for ; Thu, 5 Dec 2013 10:54:52 -0800 (PST) Received: from Philemon (static-50-47-50-163.sttl.wa.frontiernet.net [50.47.50.163]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id ECF462CA0E; Thu, 5 Dec 2013 10:54:48 -0800 (PST) From: "Jim Schaad" To: Date: Thu, 5 Dec 2013 10:53:22 -0800 Message-ID: <00dd01cef1eb$45fc8a30$d1f59e90$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00DE_01CEF1A8.37D99850" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7xcocOBFmvf01ESCiMIS2Uq712qQ== Content-Language: en-us Cc: radext@ietf.org Subject: [radext] Review comments for draft-ietf-radext-dynamic-discovery-08 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 18:54:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DE_01CEF1A8.37D99850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Here are a set of comments on the most recent draft: 1. Here is a question out of ignorance, is there going to be a potential problem with DIME about the service tags that are being requested? These concepts are used for Diameter as well and we are trying to reserve them as being RADIUS specific in this context. 2. In section 2.1.1.2 paragraph 4 - it is not clear to me if it would be legal for me to retry a TLS handshake if I had a second credential that the server might find acceptable. The current language appears to say no it would not be. 3. In section 2.1.1.3 paragraph 1 - Suggested sentence #2 Since the dynamic discover algorithm does not have provisions to establish confidential keying material between the RADIUS/TLS client (i.e. the server which executes the discovery algorithm) and the RADIUS/TLS server which was discovered, TLS-PKS ciphersuites cannot be used for in the subsequent TLS handshake. 4. In section 2.1.1.3.1 paragraph 3 - Section 2.2 should/does have the comparison rules for dealing with NAIrealms as an other name. Remove the re-statement here as it is not a clear statement of the algorithm. Move the table of examples to section 2.2 as part of the description there on how to do the comparisons. 5. In section 2.1.1.3.2 s/is:/is to/ 6. In section 2.1.1.3.2 last paragraph: It is not clear to me what shortcomings can and cannot be mitigated by this method. The TLS tunnel to the RADIUS server is not part of the system so that the hostile server could just reflect to the real server and the EAP would be happy while the hostile server can both snoop and change answers and questions in the middle. Can you be more explicit about what you think this addresses? 7. In section 2.1.1.3.4: I think that a section name along the lines of "Client Authentication Issues" is much more informative than "Remark" 8. In section 2.1.2: I think that the last two sentences would be better either in a common section or stated separately in the appropriate sections for SRV and NAPTR records respectively. 9. Section 2.1.3 - the section title could be more descriptive of what you are saying in this section 10. Section 2.2 - Move the comparison rules to this section. I believe that they can be stated much more clearly if you put them as decompose into dot separated items. Compare the items on a byte-by-byte comparison. A star in the first decomposed item matches all, a star in any other location is a match failure. (Although better written than that.) 11. I have attached an ASN.1 module that uses the RFC 5912 2002 ASN.1 modules and would request that you use that instead. I note that you think you have a module number but not a other-name number. I would be surprised if this is the case and would have expected that both were issued at the same time. 12. Section 3.1 - Not sure that I understand the reasoning for item b. 13. In Section 3.4.3 step 13 - should the 'or' be 'and/or' as it would seem that one could do a lookup for both _tcp and _udp if desired. An input or output to the algorithm may need to be if udp or tcp is the desired mechanism to use. (I don't see a comparable selection in the NAPTR processing.) 14. In section 4 paragraph 1/2 - It is not clear to me if these paragraphs are saying that DNS is required. If this is not the case then you should be more explicit about what being trusted means for an output. From the "even if" sentence it would appear nothing. 15. In section 5 - I am having a problem with the fact that you are saying that big clearing houses are no longer a problem. On the mailing list you have explicitly stated that this is still a standard configuration that will exist. It is also going to be unknown to either the user and to operators if a clearing house is being used. 16. In section 5 - it is not clear which of the benefits are from just using TLS/DTLS and which are actually from dynamic discovery. (Passive observers is just a TLS/DTLS benefit and can be done for classic as well.) 17. In section 5 - there probably needs to be made a statement that these benefits only accrue to the link for which the dynamic discovery was done. Other links may not have the same protection. Jim ------=_NextPart_000_00DE_01CEF1A8.37D99850 Content-Type: application/octet-stream; name="dynamic.asn" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dynamic.asn" PKIXServiceNameSAN93 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-dns-srv-name-93(40) } DEFINITIONS EXPLICIT TAGS ::=3D BEGIN -- EXPORTS ALL -- IMPORTS id-pkix FROM PKIX1Explicit-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} -- from RFC 5280 OTHER-NAME FROM PKIX1Implicit-2009 {iso(1) identified-organization(3) dod(6) internet(1) = security(5) mechanisms(5) pkix(7) id-mod(0) = id-mod-pkix1-implicit-02(59)} ; -- Service Name Object Identifier id-on OBJECT IDENTIFIER ::=3D { id-pkix 8 } id-on-nai OBJECT IDENTIFIER ::=3D { id-on 99999 } -- Service Name naiRealm OTHER-NAME ::=3D { NAIRealm IDENTIFIED BY { id-on-nai }} NAIRealm ::=3D UTF8String (SIZE (1..MAX)) END ------=_NextPart_000_00DE_01CEF1A8.37D99850-- From stefan.winter@restena.lu Tue Dec 17 08:22:56 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74FF1AE19F for ; Tue, 17 Dec 2013 08:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_28=0.6, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.538, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKVac6UsuFcA for ; Tue, 17 Dec 2013 08:22:53 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 146751AE04D for ; Tue, 17 Dec 2013 08:22:52 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 3DCEF1058B; Tue, 17 Dec 2013 17:22:51 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 2412A10583; Tue, 17 Dec 2013 17:22:51 +0100 (CET) Message-ID: <52B07A58.8030007@restena.lu> Date: Tue, 17 Dec 2013 17:22:48 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: radext@ietf.org, Jim Schaad References: <00dd01cef1eb$45fc8a30$d1f59e90$@augustcellars.com> In-Reply-To: <00dd01cef1eb$45fc8a30$d1f59e90$@augustcellars.com> X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QAV7vXXI35xme81T0H5XOh4xUekqabLPR" X-Virus-Scanned: ClamAV Subject: Re: [radext] Review comments for draft-ietf-radext-dynamic-discovery-08 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 16:22:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QAV7vXXI35xme81T0H5XOh4xUekqabLPR Content-Type: multipart/mixed; boundary="------------070106080509060903080109" This is a multi-part message in MIME format. --------------070106080509060903080109 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jim, > Here are a set of comments on the most recent draft: Thanks a lot for this next round of in-depth review. Way to go! > 1. Here is a question out of ignorance, is there going to be a potenti= al > problem with DIME about the service tags that are being requested? The= se > concepts are used for Diameter as well and we are trying to reserve the= m as > being RADIUS specific in this context. The development of the RADIUS draft was done in sync with the Diameter one. The service tags are fed from a disjoint pool of service denominatio= ns: aaa+ is a common prefix { auth, acct, dynauth } is the suffix set used in RADIUS ap[Diameter Application Integer code] is the suffix used in Diameter So where RADIUS has constructs like "aaa+auth", Diameter has "aaa+ap123"; there are no clashes. See RFC6408 section 3 for details. > 2. In section 2.1.1.2 paragraph 4 - it is not clear to me if it would = be > legal for me to retry a TLS handshake if I had a second credential that= the > server might find acceptable. The current language appears to say no i= t > would not be. Well... generally, this case would not happen; RFC6614 RECOMMENDS that the other side of the TLS negotiation should indicate which CAs it trusts, so that the respective other side will be able to pick a fitting certificate on first try. However, where that SHOULD is not implemented, or where the client has multiple certs from the same CA, some suitable, some not, there may arise situations where a retry is unavoidable. I've changed my working copy to state: " ... Such TLS handshake failures are permanently fatal and not eligible for retry, unless the connecting client has more X.509 certificates to try; in this case, a retry with the remainder of its set of certificates SHOULD be attempted." > 3. In section 2.1.1.3 paragraph 1 - Suggested sentence #2 > Since the dynamic discover algorithm does not have provisions to > establish confidential keying material between the RADIUS/TLS client (i= =2Ee. > the server which executes the discovery algorithm) and the RADIUS/TLS s= erver > which was discovered, TLS-PKS ciphersuites cannot be used for in the > subsequent TLS handshake. Sounds clearer than my wording - I've updated my working copy with that sentence. Thanks! > 4. In section 2.1.1.3.1 paragraph 3 - Section 2.2 should/does have the= > comparison rules for dealing with NAIrealms as an other name. Remove t= he > re-statement here as it is not a clear statement of the algorithm. Mo= ve > the table of examples to section 2.2 as part of the description there o= n how > to do the comparisons. Good point. Removed from 2.1.1.3.1 and moved examples in my working copy.= > 5. In section 2.1.1.3.2 s/is:/is to/ Changed. I used the same construct in 2.1.1.3.1 - changed that one, too. > 6. In section 2.1.1.3.2 last paragraph: It is not clear to me what > shortcomings can and cannot be mitigated by this method. The TLS tunne= l to > the RADIUS server is not part of the system so that the hostile server = could > just reflect to the real server and the EAP would be happy while the ho= stile > server can both snoop and change answers and questions in the middle. = Can > you be more explicit about what you think this addresses? Using EAP allows the authenticating entity to detect if the final destination was changed; i.e. if we arrived at a different EAP peer than he should. Using EAP does not prevent the "reflection" that you bring up in your remark. If such a reflection is put in place, EAP at least assures that the hostile server can't see the user's password (and username, if anon outer IDs are used). Some personal information may leak anyway if it's transported in otherwise unprotected RADIUS attributes (say, Calling-Station-Id). I guess I should put those same explanations into the draft. :-) Here's my go on a text describing it: "The shortcomings in server identification can be partially mitigated by using the RADIUS infrastructure only with authentication payloads which provide mutual authentication and credential protection (i.e. EAP types passing the criteria of [RFC4017]): using mutual authentication prevents the hostile server from mimicking the real EAP server (it can't terminate the EAP authentication unnoticed because it does not have the server certificate from the real EAP server); protection of credentials prevents the impersonating server from learning usernames and passwords of the ongoing EAP conversation (other RADIUS attributes pertaining to the authentication, such as the EAP peer's Calling-Station-ID, can still be learned though)." > 7. In section 2.1.1.3.4: I think that a section name along the lines = of > "Client Authentication Issues" is much more informative than "Remark" = I've changed it to "Client Authentication and Authorisation" Is that okay? > 8. In section 2.1.2: I think that the last two sentences would be bett= er > either in a common section or stated separately in the appropriate sect= ions > for SRV and NAPTR records respectively. They are stated in their respective sections already; they are listed in 2.1.1 because the S-NAPTR requires them there; they are referenced in 2.1.2 because they also make sense in this other context. To be honest, I think that moving "Definition of Conditions for Retry/Failure" and "Server Identification and Handshake" may look cleaner from text design perspective, but ultimately make the reading for implementers harder. If I wanted to implement 2.1.1 NAPTR lookups, I'd be happy to have everything confined in that section. It's just word-smithing anyway - if folks on the list tell me that I'm odd and Jim's suggestion makes way more sense, please let me know and I'll merrily change it. > 9. Section 2.1.3 - the section title could be more descriptive of what= you > are saying in this section I've changed the section name to "Optional name mangling"; this should capture the content more accurately. > 10. Section 2.2 - Move the comparison rules to this section. I believe= that > they can be stated much more clearly if you put them as decompose into = dot > separated items. Compare the items on a byte-by-byte comparison. A sta= r in > the first decomposed item matches all, a star in any other location is = a > match failure. (Although better written than that.) I now basically copied in what was previously in 2.1.something: " The comparison of a NAIRealm to the NAI realm as derived from user input with this algorithm is a byte-by-byte comparison, except for the optional leftmost dot-separated part of the value whose content is a single "*" character; such labels match all strings in the same dot-separated part of the NAI realm. If at least one of the sAN:otherName:NAIRealm values matches the NAI realm, the server is considered authorized; if none matches, the server is considered unauthorized." > 11. I have attached an ASN.1 module that uses the RFC 5912 2002 ASN.1 > modules and would request that you use that instead. I note that you t= hink > you have a module number but not a other-name number. I would be surp= rised > if this is the case and would have expected that both were issued at th= e > same time. Ehh. Rright. Probably :-) I don't know enough about ASN.1 and module vs otherName numbers. I'll merrily copy&paste your definition. :-) I can't help but notice that there are still mentions of SRVName in it (PKIXServiceNameSAN93, id-mod-dns-srv-name-93(40) ). Could it be that I initally forgot to replace them with NAIRealmName equivalents, and you kept them in by c&p? I guess we should take another close look at the *exact* bytes of this ASN.1 definition after the next rev... > 12. Section 3.1 - Not sure that I understand the reasoning for item b.= Routing of DynAuth packets is asynchronous to that of authentication requests; and the DynAuth Server which can handle DynAuth packets could be different from the authentication server in that domain. So, both need to be configurable and be discovered independently. They both take an input in form of a domain name though, so by using two different service tags, they can both use the same algorithm to discover their respective targets: a) to discover RADIUS servers which can authenticate users b) to discover DynAuth servers for a domain which can receive DynAuth packets to alter user sessions. Should I maybe reference RFC5176 for clarity regarding b) ? I do in the service tag table, but a little more verbosity here may not hurt. Please let me know. > 13. In Section 3.4.3 step 13 - should the 'or' be 'and/or' as it woul= d > seem that one could do a lookup for both _tcp and _udp if desired. An = input > or output to the algorithm may need to be if udp or tcp is the desired > mechanism to use. (I don't see a comparable selection in the NAPTR > processing.) Yes; it's a non-exclusive OR. It depends on the capabilities of the RADIUS client which executes the algorithm... if it only implements TCP/TLS, it would only query for _tcp; if it supports both, it could try both labels (which one it prefers is out of scope though). NAPTR doesn't need this decision point - the NAPTR RR authoritatively tells the querying entity which variant to try in which order. > 14. In section 4 paragraph 1/2 - It is not clear to me if these paragr= aphs > are saying that DNS is required. If this is not the case then you shou= ld be > more explicit about what being trusted means for an output. From the "= even > if" sentence it would appear nothing. DNS - trust neither the resulting IP/port nor infer authorisation DNSSEC - trust the IP/port, but still don't inter authorisation (So, use DNSSEC or not, you still have to do extra work afterwards) Actually, the section would read more clearly if I'd simply remove the first para - it's redundant because the first sentence of para 2 says it all. I've removed the first para, does this clear up the ambiguity? > 15. In section 5 - I am having a problem with the fact that you are sa= ying > that big clearing houses are no longer a problem. On the mailing list = you > have explicitly stated that this is still a standard configuration that= will > exist. It is also going to be unknown to either the user and to operat= ors > if a clearing house is being used. I don't think I'm saying that they are not a problem any more. The section states that discovery can technically make them obsolete if the operators in a consortium really want that. There may be reasons unrelated to discovery which make them not want that. That's a pity, but nothing this draft can help with (and the second bullet makes clear that proxies are likely to remain in existence)= =2E Packet inspection by all kinds of intermediates is big topic these days, and I'm all for eliminating such snooping points. The TLS part does its share, IP nodes can't read stuff any more; the discovery part can do its part by taking away 0 or more intermediate RADIUS proxies. This doesn't solve all problems in the space; including that the existence of a proxy or not is not known to the end user. It also doesn't tehcnically eliminate the possibility to deploy proxies at all. If you are looking for that, we're talking of a different draft (but that is such a complex problem that I have no idea what to write into that one ;-) ) > 16. In section 5 - it is not clear which of the benefits are from just = using > TLS/DTLS and which are actually from dynamic discovery. (Passive obser= vers > is just a TLS/DTLS benefit and can be done for classic as well.)=20 That's right,the first bullet of benefits comes from RFC6614 / draft-dtls and is unrelated to dynamic discovery. I'm removing that brag right by deleting the para. I've added this though to compensate: o Even where intermediate proxies continue to be used for reasons unrelated to dynamic discovery, the number of such intermediates may be reduced by removing those proxies which are only deployed for pure request routing reasons. This reduces the number of entities which can inspect the RADIUS traffic. > 17. In section 5 - there probably needs to be made a statement that th= ese > benefits only accrue to the link for which the dynamic discovery was do= ne. > Other links may not have the same protection. I've added: o Since dynamic discovery operates on a RADIUS hop-by-hop basis, there is no guarantee that the RADIUS payload is not transmitted between RADIUS systems which do not make use of this algorithm, and possibly using other transports such as RADIUS/UDP. On such hops, the enhanced privacy is jeopardized. And this concludes my actions on your review. Phew! I'm planning to publish a roundup -09 on Friday. If you have comments before that, I'll try to get them in, if not, it's either a -10 or maybe IETF LC (as I hope we are now nearing zero bugs :-) ). Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------070106080509060903080109 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.19 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------070106080509060903080109-- --QAV7vXXI35xme81T0H5XOh4xUekqabLPR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJSsHpZAAoJEMDeajWKOdxmi4YP/jLQ6cFa6x9M3dJQ5fwBrFU7 PiJ0loxv4IcH6c15lXVWqOMEDMQyyY7uxdyxpnMQQQ6Ga8xC8HKu9vnXSafK1DSi /pTxjvWhv5UkGJqr6pWsM7BGOnEtTwAbjjRwxyW/Dlu7fkeb7SQHILdc9cD8h873 VvrXhKU1a5pLsxe6n17hnaeIx9xZ9R2/oZBTzS9C8sPFVPbKr8wywbRr87UR6Zjm AI2OHkD98y84FPcWTer7lQsrl1aEquv90OFByGR3A9jgIuLuNPd6LTcwimDPIS75 cCQ2tFn54yzymAF6qJvejKg2BPEZeGYd/lT4jv7RxY8IJtcXPx+Sjg3nZ34zTWJY NAxgkeoBzsEnqeFny+cfA47WUdxrTVoc4dMy44zPpjrpWOAh6wR0fpwVJPw7fbFE BgB1sMAD2sfaSsBzAG6/jHIYlRRA/K15Alubg9RzuQR2b3AA/dasDjIgASrXktYG msvloY3Or/9zqVrFElV6+u/5Ijp3ckbGuPBpAixj9S9X5/wcr2p7RGqUWD0hxWx3 WDq7gb61vYN5VP1V0q8BgC5Qo0J0oLbRZKgKtjMmDgX2vDnWXX4RkoyJ2W9x0zBq nchhGXaYTmw1lNa/is8HQZpxDPMpnJSsmJ0kwM2EFLQOBrQQxaJjY0y1M3LVKTMo 37OcO5M4KK1SJjTfmQAD =dyod -----END PGP SIGNATURE----- --QAV7vXXI35xme81T0H5XOh4xUekqabLPR-- From jouni.nospam@gmail.com Thu Dec 19 05:10:56 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B701F1AD8EE for ; Thu, 19 Dec 2013 05:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUdx8ThsSabl for ; Thu, 19 Dec 2013 05:10:55 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id D540E1A1F7C for ; Thu, 19 Dec 2013 05:10:54 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id q8so438275lbi.36 for ; Thu, 19 Dec 2013 05:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=f+iQEpXWYhzbW5f535+xe1cETvBLa0KZMDGaPMdFIdY=; b=SElX3ZcPsuiyPsD7ESTyo2PUSa55kdrSnBEjqCSoh01L+eqzFUNDIYyhAZHMh/yfa8 mgnT/S/2rQ4DQihUPwhWxraQDPqQrDzk/aXyxByEAX1jc9gGnt7b5HYSkSkH8LUtm3jj +NOszK2ufKdmGaaJyVioLWyNN49mFUA5QFKe/qShFJvYb1TmURMEUkiuqH4VQEE23b9F 0eS62ucL0BlN+ry86aeMO9P79qZPEW3poWlOcrJq0QS1XWFDma/n+F6mDfTkcgtUezZA eouijIDhould0jG8C1i2UtUbQ+BdSpLcb2817uyIZyS9XOFql6UMLVKFQoXjf5lhxUwv Boxw== X-Received: by 10.112.49.162 with SMTP id v2mr742188lbn.10.1387458652109; Thu, 19 Dec 2013 05:10:52 -0800 (PST) Received: from [192.168.250.106] ([194.100.71.98]) by mx.google.com with ESMTPSA id t9sm3019331lat.1.2013.12.19.05.10.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Dec 2013 05:10:51 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Dec 2013 15:10:50 +0200 Message-Id: To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Cc: Jouni Korhonen , Mauricio Sanchez , "draft-ietf-radext-radius-fragmentation@tools.ietf.org" Subject: [radext] WGLC for draft-ietf-radext-radius-fragmentation-02 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 13:10:57 -0000 Folks, This email starts a two week WGLC for = draft-ietf-radext-radius-fragmentation-02. The WGLC end 2nd Jan 2014. Express your comments and concerns in the = mailing list. If you want your comments to be properly tracked and reflected, = enter them into the Issue Tracker. - Jouni & Mauricio= From internet-drafts@ietf.org Thu Dec 19 23:13:33 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1E51AF6E5; Thu, 19 Dec 2013 23:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVpzIrP96CQm; Thu, 19 Dec 2013 23:13:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B93E1AE033; Thu, 19 Dec 2013 23:13:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131220071331.26945.14963.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2013 23:13:31 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-09.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 07:13:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADI= US/DTLS Author(s) : Stefan Winter Mike McCauley Filename : draft-ietf-radext-dynamic-discovery-09.txt Pages : 26 Date : 2013-12-19 Abstract: This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS/TLS and RADIUS/DTLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dynamic-discovery-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stefan.winter@restena.lu Thu Dec 19 23:19:33 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6721AF6EA for ; Thu, 19 Dec 2013 23:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JXtYesSTGWp for ; Thu, 19 Dec 2013 23:19:30 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 48C061AF6E7 for ; Thu, 19 Dec 2013 23:19:30 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 7D35C10583 for ; Fri, 20 Dec 2013 08:19:27 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7126710580 for ; Fri, 20 Dec 2013 08:19:27 +0100 (CET) Message-ID: <52B3EF77.9010305@restena.lu> Date: Fri, 20 Dec 2013 08:19:19 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: radext@ietf.org References: <20131220071331.26945.14963.idtracker@ietfa.amsl.com> In-Reply-To: <20131220071331.26945.14963.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CT06GtL6SFHe7PIbXQRjuc6i9rUebLfcX" X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-09.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 07:19:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CT06GtL6SFHe7PIbXQRjuc6i9rUebLfcX Content-Type: multipart/mixed; boundary="------------090203080300020606070008" This is a multi-part message in MIME format. --------------090203080300020606070008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, this new version incorporates all the updates following Jim's review. I believe the draft is now ready for another WGLC; I'd like to ask the chairs to start one. Greetings, Stefan Winter > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. >=20 > Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and = RADIUS/DTLS > Author(s) : Stefan Winter > Mike McCauley > Filename : draft-ietf-radext-dynamic-discovery-09.txt > Pages : 26 > Date : 2013-12-19 >=20 > Abstract: > This document specifies a means to find authoritative RADIUS servers= > for a given realm. It is used in conjunction with either RADIUS/TLS= > and RADIUS/DTLS. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dynamic-discovery-= 09 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------090203080300020606070008 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.19 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------090203080300020606070008-- --CT06GtL6SFHe7PIbXQRjuc6i9rUebLfcX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJSs+9/AAoJEMDeajWKOdxmtrwQALD9WE2+iKYcPm/E0j3GMJhH RBRU+Z114ZvC8MBrgeltoOUmI9E6NG/QgBQ0OvEdMEfrsAE2ZdtIazyGkNoL/Vm5 Cr8lLMkCUL1vWFNpY9uEY9NIloPQdLOqu5xWmzMBA1oMTmaQp6WLOi97vwmvVYaH PKEbpCdla9heOpqjGIKUj1H0WOw+cYA+/RofQ9pd8J4WrHkjhP0qbCpNS/2ZyThy lCpt9rFx3VndssmfvcEQRlbmcMOIH4oSDt2F/z5yyhMImabOZyMgrqdxilmS5US3 UkYg0fO5m1S1DLNJDoq8FnaQ/J0FrXd5RSfU8MzrD4LpUDOM9h+67R7dYbqMk5qf mhJLXiCZgWmJCRDnR8ntOEbn2aUNv3namhJajuCOopYXgn4nF/TetjPjJRbWyfQh iKMmh1xL7+QVJIHce7N7y3uZAhftnvDXS5o6lb9MvGrJMTG0dNMxHSndbDrrWitn vUKZ69FhG+E3Xph+HjrVd2IWj1Mufx5qxgpEI2sIzzTFLN8Fdu028cfg2usIC2ho 3QfXsaAxuyKM00fduniWBUQrlw5FVFCNlhC1dzf34i0afBPq45XZF14d/3dyCYVW R3bl2or80WmanVYp9uGTgjHrEbwJmt9UTsnm60BgYu0fEmlNIZkaV4mRjEpbyXFo X2+cdQ/owvBrYpEoaLuw =sf0j -----END PGP SIGNATURE----- --CT06GtL6SFHe7PIbXQRjuc6i9rUebLfcX-- From jouni.nospam@gmail.com Sat Dec 21 15:20:38 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0F81AE0D2 for ; Sat, 21 Dec 2013 15:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80LC9grp3p0c for ; Sat, 21 Dec 2013 15:20:37 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A74981AE0CE for ; Sat, 21 Dec 2013 15:20:36 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id eh20so1681659lab.5 for ; Sat, 21 Dec 2013 15:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KgIB8uEYQiR2E+JnVkx9VKREobhBl8DWmZwdu3XGjZQ=; b=rgyd6fQRDuuEIDw9ZAyihY2mi42ZBZJoNS3/iz49zKBtiJtHEYW+bTQvLffsaCNckI RkjRNQW9CXoxUFmNNfmw11XaqO3GWp+xOgE4MZ6ShRIxKeh+HtqTlny/065459WDPwQE ew3KfOt8OlKe6eXqejl0+MXpNzDe1MlM6Ez9LLgYIPyJM0ruv1fg2HDV65u6Cbdse2xS US95FcPtJDCQ6TPvq2SbzI/FNT2oIAGLG44mIBMiLt7cZwhUSIw968xuV5mzA1QEVTGB 2P6FI3agDtQ+lR8+x6sQTWQadD6qKTdPj5OxULqlSbVOAr02sKGwHUDprdwHnPE++/hv jJdg== X-Received: by 10.152.120.102 with SMTP id lb6mr2182887lab.37.1387668033122; Sat, 21 Dec 2013 15:20:33 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id sd11sm10252166lab.2.2013.12.21.15.20.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Dec 2013 15:20:32 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <52B3EF77.9010305@restena.lu> Date: Sun, 22 Dec 2013 01:20:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131220071331.26945.14963.idtracker@ietfa.amsl.com> <52B3EF77.9010305@restena.lu> To: Stefan Winter X-Mailer: Apple Mail (2.1510) Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-09.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2013 23:20:38 -0000 ACK. - Jouni On Dec 20, 2013, at 9:19 AM, Stefan Winter = wrote: > Hello, >=20 > this new version incorporates all the updates following Jim's review. >=20 > I believe the draft is now ready for another WGLC; I'd like to ask the > chairs to start one. >=20 > Greetings, >=20 > Stefan Winter >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the RADIUS EXTensions Working Group of = the IETF. >>=20 >> Title : NAI-based Dynamic Peer Discovery for = RADIUS/TLS and RADIUS/DTLS >> Author(s) : Stefan Winter >> Mike McCauley >> Filename : draft-ietf-radext-dynamic-discovery-09.txt >> Pages : 26 >> Date : 2013-12-19 >>=20 >> Abstract: >> This document specifies a means to find authoritative RADIUS = servers >> for a given realm. It is used in conjunction with either = RADIUS/TLS >> and RADIUS/DTLS. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-09 >>=20 >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dynamic-discovery-09 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >>=20 >=20 >=20 > --=20 > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the > recipient's key is known to me >=20 > http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66= > <0x8A39DC66.asc>_______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From jouni.nospam@gmail.com Sun Dec 29 21:00:40 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6C61AE3E8 for ; Sun, 29 Dec 2013 21:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuaUyGhspmNu for ; Sun, 29 Dec 2013 21:00:36 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 067971AE396 for ; Sun, 29 Dec 2013 21:00:35 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id ep20so5324181lab.34 for ; Sun, 29 Dec 2013 21:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=cIqAgsq8aZuG/26Y4R6AkwQbxwucmUAOvWw9f9mNZjg=; b=H/EUKjgCU2mlmlfpDj7JRWSPd1/f9ZTT8t07pSvgbPomUANJpjkrTvCInV6XhjIggV C0YAyLJdltiQudriWLB2mGCO4GBgPpHNa0jLeIZopL2h2JOwgb9lNLhlS33SocqnIiXP T/xKgWBhvVRogUi6F2Tgxi2EWT+a5IseYSQ2KCvEBJCnE/H5Pc3z2Yd27NK0Z59fAEvV wFforyCiNrTEDxeEYlBtgYUjoVM4hL+HCKy0oA6QeV78yjeSRvJ14QirLuCPZXPMYVVP s8yd3SAmdEFrLbZsWdb7z1bQqK2HErKsWKH7B0TtIANcSortN5pCYzsPHxotNxR2AAfs eyUQ== X-Received: by 10.112.131.103 with SMTP id ol7mr502959lbb.72.1388379629633; Sun, 29 Dec 2013 21:00:29 -0800 (PST) Received: from [192.168.250.112] ([194.100.71.98]) by mx.google.com with ESMTPSA id rb4sm27001549lbb.1.2013.12.29.21.00.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Dec 2013 21:00:29 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 30 Dec 2013 07:00:52 +0200 Message-Id: <15BCB5AD-55A0-4C74-B9BB-67448122EFF6@gmail.com> To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Cc: "radext-chairs@tools.ietf.org" , draft-ietf-radext-dynamic-discovery@tools.ietf.org Subject: [radext] WGLC for draft-ietf-radext-dynamic-discovery-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 05:00:40 -0000 Folks, This email starts a two week WGLC for the draft-ietf-radext-dynamic-discovery-09. The WGLC ends 13th Jan 2014. Please, review the document, submit your comments to the mailing list and also enter them into Issue Tracker. - Jouni & Mauricio From ietf@augustcellars.com Mon Dec 30 13:06:14 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6E91AE55C for ; Mon, 30 Dec 2013 13:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJDgFHj8qo0l for ; Mon, 30 Dec 2013 13:06:12 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id D014D1AE29A for ; Mon, 30 Dec 2013 13:06:12 -0800 (PST) Received: from Philemon (c-98-247-233-24.hsd1.wa.comcast.net [98.247.233.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D1C292C9F5; Mon, 30 Dec 2013 13:06:06 -0800 (PST) From: "Jim Schaad" To: Date: Mon, 30 Dec 2013 13:04:35 -0800 Message-ID: <013701cf05a2$bf28d9c0$3d7a8d40$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0138_01CF055F.B106AB30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8FooY0dqMUP08TQ++BCCzCK9OX/Q== Content-Language: en-us Cc: radext@ietf.org Subject: [radext] Multiple Extensions X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 21:06:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0138_01CF055F.B106AB30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I just noticed this when doing a fast read through. This subjectAltName MAY occur more than once in a certificate. This conflicts with section 4.2 of RFC 5280 A certificate MUST NOT include more than one instance of a particular extension. What is true is that multiple names and multiple name forms may occur in the subjectAltName extension. Jim ------=_NextPart_000_0138_01CF055F.B106AB30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I just = noticed this when doing a fast read through.

 

This subjectAltName = MAY occur more than once in a certificate.

 

This = conflicts with section 4.2 of RFC 5280

 

A = certificate MUST NOT include more than one instance of a particular = extension.

 

What is true is that multiple names and multiple name = forms may occur in the subjectAltName extension.

 

Jim

 

------=_NextPart_000_0138_01CF055F.B106AB30-- From ietf@augustcellars.com Mon Dec 30 16:47:22 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79CC1AE556 for ; Mon, 30 Dec 2013 16:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHyadPxjMHiD for ; Mon, 30 Dec 2013 16:47:20 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id E63151AE553 for ; Mon, 30 Dec 2013 16:47:19 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 028612CA33; Mon, 30 Dec 2013 16:47:13 -0800 (PST) From: "Jim Schaad" To: "'Stefan Winter'" , References: <00dd01cef1eb$45fc8a30$d1f59e90$@augustcellars.com> <52B07A58.8030007@restena.lu> In-Reply-To: <52B07A58.8030007@restena.lu> Date: Mon, 30 Dec 2013 16:45:43 -0800 Message-ID: <018301cf05c1$a2f50f70$e8df2e50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG68Osw9QBxRQd1JEph+IN2FXoiKwFp0/QZmoo7oQA= Content-Language: en-us Subject: Re: [radext] Review comments for draft-ietf-radext-dynamic-discovery-08 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 00:47:22 -0000 > -----Original Message----- > From: Stefan Winter [mailto:stefan.winter@restena.lu] > Sent: Tuesday, December 17, 2013 8:23 AM > To: radext@ietf.org; Jim Schaad > Subject: Re: [radext] Review comments for draft-ietf-radext-dynamic- > discovery-08 >=20 > Hi Jim, >=20 > > Here are a set of comments on the most recent draft: >=20 > Thanks a lot for this next round of in-depth review. Way to go! >=20 > > 11. I have attached an ASN.1 module that uses the RFC 5912 2002 = ASN.1 > > modules and would request that you use that instead. I note that = you > > think you have a module number but not a other-name number. I = would > > be surprised if this is the case and would have expected that both > > were issued at the same time. >=20 > Ehh. Rright. Probably :-) I don't know enough about ASN.1 and module = vs > otherName numbers. I'll merrily copy&paste your definition. :-) >=20 > I can't help but notice that there are still mentions of SRVName in it > (PKIXServiceNameSAN93, id-mod-dns-srv-name-93(40) ). Could it be that = I > initally forgot to replace them with NAIRealmName equivalents, and you > kept them in by c&p? >=20 > I guess we should take another close look at the *exact* bytes of this > ASN.1 definition after the next rev... The process of getting OIDs assigned is being changed. I will create a = new module and IANA section to deal with this and send it to you by the end = of the week. >=20 > > 12. Section 3.1 - Not sure that I understand the reasoning for item = b. >=20 > Routing of DynAuth packets is asynchronous to that of authentication > requests; and the DynAuth Server which can handle DynAuth packets = could > be different from the authentication server in that domain. >=20 > So, both need to be configurable and be discovered independently. They > both take an input in form of a domain name though, so by using two > different service tags, they can both use the same algorithm to = discover their > respective targets: >=20 > a) to discover RADIUS servers which can authenticate users >=20 > b) to discover DynAuth servers for a domain which can receive DynAuth > packets to alter user sessions. >=20 > Should I maybe reference RFC5176 for clarity regarding b) ? I do in = the service > tag table, but a little more verbosity here may not hurt. Please let = me know. >=20 It would seem to me that this should then be the case of accounting as = well. It might be better to say that it needs to be unique for each service = and then state that new conversations would be needed for each service. Is DynAuth always a single round trip? > > 13. In Section 3.4.3 step 13 - should the 'or' be 'and/or' as it > > would seem that one could do a lookup for both _tcp and _udp if > > desired. An input or output to the algorithm may need to be if udp = or > > tcp is the desired mechanism to use. (I don't see a comparable > > selection in the NAPTR > > processing.) >=20 > Yes; it's a non-exclusive OR. It depends on the capabilities of the = RADIUS > client which executes the algorithm... if it only implements TCP/TLS, = it would > only query for _tcp; if it supports both, it could try both labels = (which one it > prefers is out of scope though). >=20 > NAPTR doesn't need this decision point - the NAPTR RR authoritatively tells > the querying entity which variant to try in which order. That makes sense. However the question does arise if the mechanism then needs to be an output. tuples {hostname; port; protocol; order/preference; Effective TTL} >=20 > > 14. In section 4 paragraph 1/2 - It is not clear to me if these > > paragraphs are saying that DNS is required. If this is not the case > > then you should be more explicit about what being trusted means for = an > > output. From the "even if" sentence it would appear nothing. >=20 > DNS - trust neither the resulting IP/port nor infer authorisation = DNSSEC - > trust the IP/port, but still don't inter authorisation >=20 > (So, use DNSSEC or not, you still have to do extra work afterwards) >=20 > Actually, the section would read more clearly if I'd simply remove the first > para - it's redundant because the first sentence of para 2 says it = all. >=20 > I've removed the first para, does this clear up the ambiguity? Yes that does make it better >=20 > > 15. In section 5 - I am having a problem with the fact that you are > > saying that big clearing houses are no longer a problem. On the > > mailing list you have explicitly stated that this is still a = standard > > configuration that will exist. It is also going to be unknown to > > either the user and to operators if a clearing house is being used. >=20 > I don't think I'm saying that they are not a problem any more. The = section > states that discovery can technically make them obsolete if the = operators in a > consortium really want that. >=20 > There may be reasons unrelated to discovery which make them not want > that. That's a pity, but nothing this draft can help with (and the = second bullet > makes clear that proxies are likely to remain in existence). >=20 > Packet inspection by all kinds of intermediates is big topic these = days, and I'm > all for eliminating such snooping points. The TLS part does its share, = IP nodes > can't read stuff any more; the discovery part can do its part by = taking away 0 > or more intermediate RADIUS proxies. >=20 > This doesn't solve all problems in the space; including that the = existence of a > proxy or not is not known to the end user. It also doesn't tehcnically > eliminate the possibility to deploy proxies at all. >=20 > If you are looking for that, we're talking of a different draft (but = that is such a > complex problem that I have no idea what to write into that one ;-) ) I still find this paragraph somewhat confusing. How about: This protocol allows for RADIUS clients to identify and directly connect = to the RADIUS home server. This can eliminate the use of clearinghouses to = do forwarding of requests, it also eliminates the ability of the = clearinghouse to then aggregate the user information that flows through it. However, there exist reasons why clearinghouses might still be used. One reason = to keep a clearinghouse is to act as a gateway for multiple backends in a company. - I would rather talk about your issue in Eduroam as the reason as that = is probably more interesting, but I don't remember the details anymore. Jim > And this concludes my actions on your review. Phew! >=20 > I'm planning to publish a roundup -09 on Friday. If you have comments > before that, I'll try to get them in, if not, it's either a -10 or = maybe IETF LC (as I > hope we are now nearing zero bugs :-) ). >=20 > Greetings, >=20 > Stefan Winter >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et de > la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key > is known to me >=20 > = http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC6 > 6