Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
+1. I'd +10 if I could :-) One thing that would be helpful is to encourage the use of Diffie-Hellman everywhere. Even without certificates that can be trusted, we can eliminate the ability of casual, dragnet-style surveillance. Sure, an attacker can still do a MITM attack. But (a) people who are more clueful can do certificate pinning/verification, and (b) if the NSA is really putting data taps into tier 1 providers' high speed interconnects, they can only carry out MITM attacks on a bulk scale by placing racks and racks of servers, which will require significant amounts of cooling and power, in places that are much more likely where they would be noticed. It's no longer a data tap hidden away somewhere in a closet near a tier 1's NAP. For too long, I think, we've let the perfect be the enemy of the good. Using TLS with DH to secure SMTP connections is valuable even if it is subject to MITM attacks, and even if the NSA/FBI can hand a National Security Letter to the cloud provider. At least this way they will be forced to go the NSL route (and it will show up in whatever transparency reports that Google or Microsoft or Facebook are allowed to show to the public), or spend $$$ on huge racks of servers in public data centers, which maybe means less money to subvert standards setting activities. Although perfect security is ideal, increasing the cost of casual style dragnet surveillance is still a Good Thing. - Ted -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale 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=getsearch=0xC0DE6A358A39DC66 0x8A39DC66.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard
Hi, When relying on S-NAPTR (RFC3958), redirection is only possible inside sub-domains of the original domain name. I don't think that's true. RFC3958 has exactly this use case in it's first example section (2.2): a domain example.com redirects service EM:protA to another domain, namely someisp.example - with the non-terminal flag, as I described in my original mail. This is absolutely a different domain name. This is a restriction compared to the use of normal NAPTR and REGEXP. While making my own experiences with NAPTR, I learned that there is no normal use of NAPTR. NAPTR records are not allowed to be used in the wild without a valid DDDS specification defining its exact semantics. That is precisely the reason why RFC3588 had to be revised in that regard. RFC3958 provides that semantics, so it was a natural choice to re-base Diameter's usage in an S-NAPTR. The following recommendations can be also found in the RFC6733: The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query. Actually, I don't even understand the SHOULD here without any clarification on what to do if not... but it is another debate. I now see that RFC6733 has put this IMHO arbitrary restriction in place. It really serves no particular purpose; if there was some thinking behind it, then that really should have been explained in the document. I would tend to ignore that SHOULD if I were implementing Diameter (I'm not :-) ). Different domain names are perfectly in scope for S-NAPTRs, and you would have to consciously lobotomise libraries or code snippets to *not* permit redirections to other domains. We are also regularly using s-flag S-NAPTRs in eduroam and RADIUS Dynamic Discovery to point to a delegate RADIUS server residing in a different domain. It's just normal operations. This limitation in RFC6733 is at best funny IMHO. Therefore, my understanding is that the use of S-NAPTR is not suitable for redirection when the target domain name is different from the original one. And the current draft proposes to allow any kind of redirection without any impact on existing DNS infra. I would rather take a very good look at the section in RFC6733 that discourages other domain names in the replacement. It's more like an erratum for me; and if that restriction were away you would have a working solution to your redirection problem with zero effort. And anyway, it's a SHOULD without considerations or consequences attached. Which makes it more of a DONTCARE anyway ;-) But as I said, it is only based on my understanding and I'm not an expert on DNS. I don't think DNS is the problem here. It's more that Diameter butchers its NAPTR usage unnecessarily. Greetings, Stefan Winter Regards, Lionel -Message d'origine- De : dime-boun...@ietf.org [mailto:dime-boun...@ietf.org] De la part de Stefan Winter Envoyé : lundi 19 août 2013 10:16 À : d...@ietf.org; 'IETF Discussion Mailing List' Objet : Re: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard Hello, The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Realm-Based Redirection In Diameter' draft-ietf-dime-realm-based-redirect-11.txt as Proposed Standard Sorry for bringing this up so late, but as I was writing my own dynamic discovery draft for RADIUS, it occured to me that the usage of S-NAPTR for Diameter brings a built-in support to signal realm-based redirect *if* S-NAPTR discovery is used. That only affects this document periphally; it describes realm-based redirect for agent-based redirects, not for DNS-based; but still, the wording in section 2 implies that using a realm-based-redirect-aware Diameter agent is the only choice, and I think that should be rectified. The mechanism for S-NAPTR realm-based redirect is built into the S-NAPTR spec by allowing for non-terminal lookups; this is signalled by having neither an s flag (for SRV targets) nor an a flag (for A/ targets); but instead an (empty) flag. The replacement string in the NAPTR record is then the label of /another/ NAPTR lookup; that lookup is then to be performed with the same service/protocol tag. That makes the whole realm-based redirect problem very easy protocol-wise. Consider a realm foo.example who wants to tell its Diameter peers that its realm's application ID 123 is from now on served from example.com. It puts into DNS foo.example. 43200 IN NAPTR 100 10 aaa+ap123:diameter.tls example.com A client who got this answer would then query for example.com NAPTR aaa+ap123:diameter.tls and would get example.com's servers via SRV or A/ records as configured by the admins of example.com. This is described in section 2.2.3 of RFC3958. Now for the wording in the draft: Sction 2: the first para needs a bit
Re: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard
Hi, Thank you for quick feedback. I agree with your analysis. I think that we should provide more info on the possible use of S-NAPTR for realm-based redirection. Taking into account your proposal, what do you think of the following proposed changes: The new text reads pretty well. One thing worth considering is maybe: this draft already updates RFC6733. It may be worth making explicit that the RFC6733 SHOULD regarding same-domain targets is being made obsolete in by this draft. One more sentence in the section 2 text below should do the trick: NEW: Using the S-NAPTR DDDS application [RFC3958], the DNS-based dynamic peer discovery mechanism defined in the Diameter base protocol [RFC6733] provides a simple mechanism for realm-based redirection. When S-NAPTR is used for peer discovery, redirection of Diameter request from the original realm to a new realm may be performed by updating the existing NAPTR resource records for the original realm as follow: the NAPTR RR for the desired application(s) and supported application protocol(s) provided by the new realm will have an empty FLAG field and the REPLACEMENT field will contain the new realm to use for the next DNS lookup. ADD: The new realm can be arbitrary; the restriction in RFC6733 that the NAPTR replacement field SHOULD match the domain of the original query does not apply for realm-based redirect purposes. All the rest of the text is fine. Greetings, Stefan Winter However, the use of DNS-based dynamic peer discovery is optional for Diameter implementations. For deployments which do not make use of S-NAPTR peer discovery, support of realm-based redirection MUST be specified as part of functionality supported by a Diameter application. In this way, support of the considered Diameter application (discovered during capabilities exchange procedures as defined in Diameter base protocol [RFC6733]) indicates implicit support of the realm-based redirection mechanism. Designers of new applications can incorporate the mechanism specified here into their application by normative reference to this document. The result of making realm-based redirection an application-specific behaviour is that it cannot be performed by a redirect agent as defined in [RFC6733], but MUST be performed instead by an application-aware Diameter node (Diameter server or proxy) (hereafter called a Realm-based Redirect Server). An application can specify that realm-based redirection operates only on complete sessions beginning with the initial message, or on every message within the application, even if earlier messages of the same session were not redirected. This distinction matters only when realm-based redirection is first initiated. In the former case, existing sessions will not be disrupted by the deployment of realm- based redirection. In the latter case, existing sessions will be disrupted if they are stateful. Regards, Lionel -Message d'origine- De : Stefan Winter [mailto:stefan.win...@restena.lu] Envoyé : mardi 20 août 2013 08:37 À : MORAND Lionel OLNC/OLN Cc : d...@ietf.org; 'IETF Discussion Mailing List' Objet : Re: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard Hi, When relying on S-NAPTR (RFC3958), redirection is only possible inside sub-domains of the original domain name. I don't think that's true. RFC3958 has exactly this use case in it's first example section (2.2): a domain example.com redirects service EM:protA to another domain, namely someisp.example - with the non-terminal flag, as I described in my original mail. This is absolutely a different domain name. This is a restriction compared to the use of normal NAPTR and REGEXP. While making my own experiences with NAPTR, I learned that there is no normal use of NAPTR. NAPTR records are not allowed to be used in the wild without a valid DDDS specification defining its exact semantics. That is precisely the reason why RFC3588 had to be revised in that regard. RFC3958 provides that semantics, so it was a natural choice to re-base Diameter's usage in an S-NAPTR. The following recommendations can be also found in the RFC6733: The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query. Actually, I don't even understand the SHOULD here without any clarification on what to do if not... but it is another debate. I now see that RFC6733 has put this IMHO arbitrary restriction in place. It really serves no particular purpose; if there was some thinking behind it, then that really should have been explained in the document. I would tend to ignore that SHOULD if I were implementing Diameter (I'm not :-) ). Different domain names are perfectly in scope for S-NAPTRs, and you would
Re: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard
Hello, The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Realm-Based Redirection In Diameter' draft-ietf-dime-realm-based-redirect-11.txt as Proposed Standard Sorry for bringing this up so late, but as I was writing my own dynamic discovery draft for RADIUS, it occured to me that the usage of S-NAPTR for Diameter brings a built-in support to signal realm-based redirect *if* S-NAPTR discovery is used. That only affects this document periphally; it describes realm-based redirect for agent-based redirects, not for DNS-based; but still, the wording in section 2 implies that using a realm-based-redirect-aware Diameter agent is the only choice, and I think that should be rectified. The mechanism for S-NAPTR realm-based redirect is built into the S-NAPTR spec by allowing for non-terminal lookups; this is signalled by having neither an s flag (for SRV targets) nor an a flag (for A/ targets); but instead an (empty) flag. The replacement string in the NAPTR record is then the label of /another/ NAPTR lookup; that lookup is then to be performed with the same service/protocol tag. That makes the whole realm-based redirect problem very easy protocol-wise. Consider a realm foo.example who wants to tell its Diameter peers that its realm's application ID 123 is from now on served from example.com. It puts into DNS foo.example. 43200 IN NAPTR 100 10 aaa+ap123:diameter.tls example.com A client who got this answer would then query for example.com NAPTR aaa+ap123:diameter.tls and would get example.com's servers via SRV or A/ records as configured by the admins of example.com. This is described in section 2.2.3 of RFC3958. Now for the wording in the draft: Sction 2: the first para needs a bit of a rewrite to factor in S-NAPTR's capabilities. I suggest something along the lines of: Realm-based redirection is implicitly a part of the Diameter base protocol, but only where peer discovery using S-NAPTR is used (section 5.2 of [RFC6733], by using the non-terminal S-NAPTR flag). This allows for both application-specific realm-based redirects, and for application-agnostic (unconditional) realm-based redirects, and does not require any Diameter agents. For deployments which do not make use of S-NAPTR peer discovery, support of realm-based redirection MUST be specified as part of functionality supported by a Diameter application. (... continue with the rest of the section ...) Greetings, Stefan Winter The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-08-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Message redirection is a basic capability provided by the Diameter base protocol. In its conventional form, message redirection is performed by an application-independent redirect agent, which returns one or more individual hosts to the message sender as possible destinations of the redirected message. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which that can be achieved. New applications may incorporate this capability by reference to the present document. Because the redirection mechanism is application-specific, it must be performed by a Diameter server or proxy rather than a basic redirect agent as defined in the Diameter base protocol. A new term, Realm- based Redirect Server, is introduced in this document to differentiate the application-specific nature of realm-based redirection from the conventional Diameter redirection performed by a basic redirect agent. This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1254/ ___ DiME mailing list d...@ietf.org https://www.ietf.org/mailman/listinfo/dime -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature
Re: Last Call: draft-ietf-emu-eap-tunnel-method-07.txt (Tunnel EAP Method (TEAP) Version 1) to Proposed Standard
. It is good that NAIs are not mentioned normatively in that section; after all Peer-Ids and also anonymous outer identities may or may not be NAI realms - they can also be simple strings with no particular structure. But since they can be just that - simple strings with no structure - there is also no encoding known for these incoming strings. I know, TEAP doesn't (and doesn't *have to*) care about the outer identities, because they happen outside of itself and are not of importance for neither its phase 1 or 2. And still, some spec needs to say something about the encoding! Or we'll never have clarity about what's coming in. After taking a step back, looking at where to properly fix things, I'm becoming more and more convinced that chasing individual EAP methods to include normative language about something that happens outside their own method-protocol; and in TEAP's case being at the whim that some other EAP method which happens to have been configured as TEAPs inner method has already done its homework to include provisions about exporting its inner IDs in a sane format for the TEAP exchange as a whole to become deterministically encoded is - impractical. The much more straightforward approach is to mandate EAP (core) to always force use of UTF-8 for EAP-Response/Identity. In summary (kudos for reading this far!) == IMHO, TEAP should fix the following points * Peer-Id and Server-Id should become deterministic. * When discussing NAIs, mentions of RFC4282 should be removed, or qualified so that readers of spec are urged to read (exclusively) its successor as soon as it becomes available. Things that might be tackled in TEAP, but my personal preference would be to do that in EAP core: * Specify the encoding in which phase 2's Peer-Id is used during the EAP negotiation that precedes the TEAP exchange. If Peer-Ids are not used (i.e. identity privacy support is enabled), specify in which encoding the privacy-preserving identity hints are expected. Thanks for reading this :-) Note how I did not go into detail about normalization; similar principles apply here, but the mail is long enough. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature
Re: Internationalization and draft-ietf-abfab-eapapplicability
Hi, We don't get to place requirements on applications except to say what they need to do to use EAP. The protocol requirement for that is that applications using EAP need to know what character set they have so that EAP can convert the identity to UTF-8 and so that EAP methods can do any needed conversions. That text sounds pretty good, and is probably all ABFAB needs to say about this. I'm still not happy with the i18n situation in EAP; especially that EAP itself doesn't always know its requirements regarding encoding and normalization. I think the basic problem is that identities and other credentials are eap-type specific and one might expect that neither core EAP nor the AAA transport have to care about what an EAP method thinks it wants as encoding. But that isn't true, since at least the Identity part (not the passwords; I'm not saying these would need to be normalised at all) may be needed by the EAP method, but they transpire through to the EAP-Identity and RADIUS/other-AAA User-Names. It's a spill-over effect, where an EAP method's decisions re encoding and normalisation impose something on other protocols. Due to that, an EAP method's way of constructing *identities* needs to be regulated so that the method, core EAP, and AAA transports can get along. Nothing of this needs to happen in ABFAB, but I think work needs to be done. Either by modifying EAP itself to impose a common encoding and maybe normalisation on EAP-Identity (which in turn forces EAP methods to use that same encoding and/or normalisation in their outer or only phase), or by making sure all EAP methods use an encoding that does not create problems on EAP core and the AAA layer. I think this really has force use of UTF-8 written all over it. The question for me is which path to take, and where/who does the work. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature
Re: Internationalization and draft-ietf-abfab-eapapplicability
Hi, After reading this document, I believe that this document omits discussion of an important aspect, which is internationalization. Since the contents of the EAP Identity and RADIUS User-Name attributes are specified to be encoded in UTF-8, application protocols that utilize encodings other than UTF-8 for user identities and passwords could have issues utilizing EAP (and RADIUS). Currently RFC 4282bis proposes that all EAP implementations normalize identities and passwords before utilizing them, and therefore application protocols that do not do this will be at variance with RFC 4282bis. IMHO the document needs to state what the internationalization requirements are for application-layer protocol use of EAP. There are potential workarounds, such as requiring that application protocols convert identities and passwords to UTF-8 prior to use of EAP, or modifying RFC 4282bis so as to require normalization in RADIUS proxies or servers. However, without fixes being applied and/or changes to RFC 4282bis, use of EAP by applications may not be compatible with either existing specifications or implementations. The discussion in radext on RFC4282bis was very long and much thought has gone into fixing internationalisation aspects. The fix is still partial only, because of the said uncertainties about the input encoding and normalization. RADIUS servers or proxies touching and manipulating the Identity/User-Name was seen as the bigger of two evils; the lesser one being the requirement on EAP supplicants to perform normalization on their own. If a change is needed in the eapapplicability draft, I'd prefer to change eapapplicability to be in line with 4282bis, not the other way around. Background EAP and protocols that carry it (e.g. RADIUS) assume that the EAP-Response/Identity is encoded in UTF-8. For example, RFC 3748 Section 1.2 defines displayable message as follows: Displayable Message This is interpreted to be a human readable string of characters. The message encoding MUST follow the UTF-8 transformation format [RFC2279]. Therefore EAP messages including EAP Identity and Notification that are described as displayable messages have a UTF-8 encoding requirement applied to them. I disagree with your reading of RFC3748. It's true that displayable messages need to be encoded in UTF-8; but the document does not state that an EAP-Response/Identity is a displayable message. Section 5.1 of RFC3748 uses the term displayable message several times, but never in conjunction with the Identity *response*: An optional displayable message MAY be included to prompt the peer in the case where there is an expectation of interaction with a user. (which is for the request, and it is optional) and later on: Type-Data This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. This is the normative language for the previous text. I keep staring at section 5.1 of that RFC and see nothing that would require the EAP-Response/Identity to be UTF-8. I also believe that the lack of being clear at that particular point is the root of all evil because it allows EAP supplicant implementers to choose arbitrary encodings for conveying the identities. It is somewhat understandable that EAP-Response/Identity was not tagged as displayable message back in the day - its purpose is not to be displayed anywhere; it's input to the authentication algorithm and is meant to be processed by an EAP server. So, if there's nothing to display, it's not a displayable message. RFC3748 would have achieved more clarity and better interop if it would have explicitly demanded the EAP-Response/Identity to be UTF-8 even though it's not a displayable message. Now, that would suggest an update to RFC3748, introducing a UTF-8 requirement at that spot. And guess what - we're writing a document that updates RFC3748! The question is: this document is about an applicability update, not a change of the on-the-wire behaviour of EAP. If we were to try and apply a proper fix to RFC3748 to make Identities UTF-8 everywhere, then the impact is way beyond ABFAB. We previously tried to make the applicability statement for all of EAP, but later decided to restrict ourselves to ABFAB-specific updates. The next best solution then would be to require that only ABFAB-using EAP supplicants are required to use UTF-8 (and possibly also require a normalisation). That would indeed solve ABFAB's i18n'ed use of EAP, but not everybody else's. That's a bit selfish, but it would certainly be better than nothing. I wonder what the other authors think about nailing down a UTF-8/NFC-normalised Identity into the draft. Greetings, Stefan Winter Since RFC 3579 Section 2.1 specifies that the EAP-Response/Identity is copied into the RADIUS User-Name Attribute: In order to permit non-EAP aware RADIUS proxies to forward
Re: Internationalization and draft-ietf-abfab-eapapplicability
Hi, I think assuming that 4282bis has reached consensus on internationalization is wildly wishful thinking at this stage. I continue to be dubious that the right parties are involved in the discussion and even if we have consensus in radext expect significant discussion at ietf last call, appsdir review and IESG review. I had the impression we are getting somewhere, but that's just a personal opinion of course. However, I absolutely agree that if an application is going to use EAP it needs to follow EAP's i18n conventions whatever those may be. A rrequirement on anti-causal investigation for current implementation efforts has never stopped us before. I also agree the current document does not speak to this. My recommendation is that we point out the issue. And say that strings used within a specific EAP method MUST follow the rules for that method. If AAA is used, strings used within AAA MUST follow the rules for the AAA protocol in use. We can add an informative citation to 4282bis as a snapshot of current thinking. Pushing the requirement down to the EAP method won't work IMHO. Take as example EAP-TTLS in RFC5281. A full-text search for UTF in it yields 0 hits; and a look at section 7.3 (EAP Identity Information) does not speak of any encodings. IMHO, not being explicit in the EAP spec itself has brought us to the i18n problems we are seeing. An EAP supplicant supporting EAP-TTLS can use latin-1 or foobar as encoding for the EAP identity; he'll send that bytestream on the wire without the encoding information being known, meaning a UTF-8 sanitisation isn't possible anywhere further down the route. The supplicant also doesn't know that the authenticator will wrap this in RADIUS, so can't be aware of the next-hop's requirement to use UTF-8. The poor pass-through authenticator now gets a blob with not valid UTF-8, and is forced to either violate RFC2865 by putting non-UTF-8 into a RADIUS User-Name, or by rejecting the entire EAP authentication for a reason the EAP supplicant can do nothing about because it doesn't know about it. In the IEEE 802.1X network access case, there's also no signalling what exactly was the reason for EAP to break; EAPoL is not very verbose. I don't know about ABFAB; GSSAPI could well have a way to signal that it choked on encoding - or not. In the end, all participants in the conversation can claim they did the right thing, and yet nothing worked. I would not support a normative reference to 4282bis. That I agree with; 4282bis is about NAIs exclusively. I could well imagine ABFAB being deployed inside an enterprise where EAP identities do not follow the NAI provisions; any restrictions on the encoding or normalization should apply to those deployments nontheless. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature
Re: Internationalization and draft-ietf-abfab-eapapplicability
Hi, Pushing the requirement down to the EAP method won't work IMHO. Further to this: now that I have EAP-TTLS on screen, its words of wisdom about EAP type selection show that it won't work quite clearly. And they are valid beyond EAP-TTLS. Section 7.3 of RFC5281 states: Note that at the time the initial EAP-Response/Identity packet is sent the EAP method is yet to be negotiated. If, in addition to EAP- TTLS, the client is willing to negotiate use of EAP methods that do not support user anonymity, then the client MAY include the name of the user in the EAP-Response/Identity to meet the requirements of the other candidate EAP methods. This was written for anonymisation reasons; but it applies to i18n as well. If EAP-Type A uses encoding X, and EAP-Type B uses encoding Y, in which encoding should the initial EAP-Response/Identity be sent? One can only hope that all the EAP types which are configured on the supplicant share one common encoding that is allowed in all of them, and that the supplicant chooses wisely. Otherwise the question above can turn into a does not compute. Sure, a half-baked answer is that the real identity is in a tunnel anyway, and the EAP type is known at that time; but that doesn't cover all cases. EAP-pwd has no tunnel, and needs to rely on the outer identity being in a format it can process. There are more untunneled EAP types. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature
Re: Internationalization and draft-ietf-abfab-eapapplicability
Hi, Sam said: Nah, you'd just be living in a different hell if you'd been explicit in the EAP spec. I know: other parts of the IETF are in that hell. The protocols are clear and everything is fine until you realize that the backend authentication systems you're dealing with are using a totally different set of rules than the protocols. That hell sucks too. [BA] I totally agree. I'm joyfully naïve here. Right now, the receiving end has no guarantees about the encoding and normalisation of the incoming string. If it doesn't match its expectations in that regard, then that's unrecoverable. In the other hell, it can be sure to receive UTF-8 in NFC, and if that doesn't match what it needs, it can convert it. In my naïve thinking, that second hell is a lot less hot and much more habitable. Could you point out where my thinking goes wrong? Also: we're dealing with writing specifications here. If our specifications are correct, and some implementations do it wrong anyway - that's their problem, right? However, none of the above matters for this document. [BA] Exactly. It's just an applicability statement, not a prescription for world peace :) Sure: we need more than an applicability statement update to achieve peace in the EAP world. But if an applicability statement update is all we can work with, we could try and do our best in that one. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature
Re: Internationalization and draft-ietf-abfab-eapapplicability
Hi, [BA] We are just talking about core EAP and RADIUS RFCs here. Internationalization of method-specific identities (and passwords) is defined by the EAP method specifications, so the Identities UTF-8 everywhere is a much broader topic (and one which I'd argue is not relevant to an ABFAB applicability statement). Indeed; sorry for the imprecise use of everywhere. What needs to be tackled is EAP's outer or only identity (for methods that don't have the luxury of sending a different identity in their method-specific payload). The next best solution then would be to require that only ABFAB-using EAP supplicants are required to use UTF-8 (and possibly also require a normalisation). [BA] I would agree with a UTF-8 requirement for EAP-Response/Identities. That is necessary in practice, because RFC 3579 requires that the EAP-Response/Identity be copied into the RADIUS User-Name attribute, and RFC 2865 Section 5.1 states that: You are conflating AAA with RADIUS. EAP-Response/Identity can be used in other contexts; I heard that some use Diameter instead of RADIUS, so any reference to RFC2865 would not apply there. And if I write MyOwnAAAProtocol and require EAP Identities in EBCDIC encoding in my equivalent of User-Name, then that's my thing alone and RFC2865 has nothing to say to me. The EAP supplicant doesn't know which AAA is going to be used behind the authenticator; so how would it know whether to use EBCDIC or UTF-8? Unless, of course, there is a place outside of RFC2865 which forces me to accept/use exclusively UTF-8. An update to RFC3748 stating that comes to mind. Internationalization of method-specific identities and passwords are up to the methods, so the document can just point this out and say see applicable RFCs. As stated elsewhere in the thread, the initial EAP-Identity needs to be sent before the EAP method is negotiated. Personally, I don't think that the ABFAB applicability statement has to mandate normalization in NAIs - that would make it depend on RFC 4282bis, and that doesn't seem necessary to me. Instead, it can just make the reader aware of RFC 4282bis and say that uses need to conform to internationalization requirements which are a work in progress. This is a cliffhanger text with a forward-reference into the future. I could live with a statement like that, but ... ... just listing 4282bis is not enough; EAP identities don't have to be NAIs - if we state that applications need to conform to that future RFC, and they read things in it like This document only defines NAIs, if you don't use NAIs, there's nothing in it for you - then implementations have a way too easy loophole to not care about i18n; they can just say: oh, we don't use NAIs. It's all unstructured identities; any presence of an @ in there is just coincidence. I could live with it very well if there is a promise to continue the cliffhanger situation with an all-encompassing update that covers all EAP Identities; be they NAIs or not and be they transported over RADIUS or not. I.e. if we can agree that updating RFC3748 with stricter i18n rules is going to be chartered work and will happen, then I can live with a cliffhanger statement of stay tuned for that update in the eapapplicability draft. Greetings, Stefan Winter That would indeed solve ABFAB's i18n'ed use of EAP, but not everybody else's. That's a bit selfish, but it would certainly be better than nothing. I wonder what the other authors think about nailing down a UTF-8/NFC-normalised Identity into the draft. Greetings, Stefan Winter Since RFC 3579 Section 2.1 specifies that the EAP-Response/Identity is copied into the RADIUS User-Name Attribute: In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. Therefore for use with EAP, the User-Name Attribute also inherits a UTF-8 encoding requirement, restricting the potential encodings permitted by RFC 2865 Section 5.1 (User-Name Attribute): The format of the username MAY be one of several forms: text Consisting only of UTF-8 encoded 10646 [7] characters. network access identifier A Network Access Identifier as described in RFC 2486 [8]. distinguished name A name in ASN.1 form used in Public Key authentication systems. -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de
Re: Internet Draft Final Submission Cut-Off Today
Hi, [...] ferkakte [...] As a German, I'm now torn apart between being flattered that we've successfully exported a German word to the U.S. and being speechlessly shocked by the way spelling was b0rked in the process. Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature
Re: Internet Draft Final Submission Cut-Off Today
Hi, [...] ferkakte [...] As a German, I'm now torn apart between being flattered that we've successfully exported a German word to the U.S. and being speechlessly shocked by the way spelling was b0rked in the process. I believe that it's actually Yiddish. yup: http://www.yiddishdictionaryonline.com/dictionary/display.php?action=searchtype=romword=farkakt still my bet would be that this Yiddish word has Germanic origins…. Here we see one of the *good* things about having an I-D cutoff deadline. One finally finds time to do /other/ things ;-) Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature
Re: [radext] Security review of draft-ietf-radext-radsec
(this model is optional to implement): Implementations SHOULD allow to configure a list of trusted certificates, identified via certificate fingerprint. Implementations MUST support SHA-1 as the hash algorithm. * TLS using TLS-PSK (this model is optional to implement) (note that some changed to this text might occur due to pending DISCUSSes and COMMENTs in the IESG review). Greetings, Stefan Winter ___ radext mailing list rad...@ietf.org https://www.ietf.org/mailman/listinfo/radext -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-radext-radsec
is only specified in the context of DynAuth (RFC5176). That attribute is listed as only allowed in a NAK as per the attribute occurence table in 5176. I would be hesitant to use Error-Cause in RADIUS Accounting packets - unless the corresponding RFCs get updated to specify that this attribute is now also to be used in Accounting semantics. And to be honest, I would even be rather against such a change, and introduce a proper Accounting-NAK packet type instead; but that's a different story. The non-ability to indicate No accounting please has been discussed in a radext wg meetint. The conclusion was that auth and acct are two separate, unrelated items. RADIUS Accounting needs to be configured differently and explicitly; so there is little risk that accounting packets are sent by chance anyway. If they are sent to the wrong place, that is an administrative error: misconfigured on the sender-side. Section 4 As a consequence, the selection of transports to communicate from a client to a server is a manual administrative action. An automatic fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- bidding attacks on the peer communication. [BA] If a fixed shared secret radsec is used alongside fallback to RADIUS/UDP, that seems more like a MUST NOT!! That paragraph was also brought up in the AD review. It was not meant in the way you perceived it; please see the thread of the AD review of this document for an extensive explanation how it was really meant. In any case, I take the point that the text is confusing for readers. While resolving the AD comments, I agreed with Dan Romascanu to reformulate this whole paragraph and move it to Security Considerations instead. I'll follow up with the new text later today. Section 6 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be able to accept connections from a large, not previously known, group of hosts, possibly the whole internet. In this case, the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer, i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks, just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs, checking critical extensions, checking subjectAltNames etc.) to prevent unauthorised connections. [BA] I'd recommend collecting this and other dynamic-discovery related material into a separate section prior to 3.1. Moved out of the document, to go into dynamic-discovery. Appendix C. Assessment of Crypto-Agility Requirements The RADIUS Crypto-Agility Requirements (link to RFC once issued here) defines numerous classification criteria for protocols that strive to enhance the security of RADIUS. It contains mandatory (M) and recommended (R) criteria which crypto-agile protocols have to fulfill. The authors believe that the following assessment about the crypto-agility properties of RADIUS/TLS are true. [BA] The Crypto-Agility RFC is now published so you should reference that. Done now in my working copy. Thanks for this extensive review, much appreciated! Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-radext-radsec
Hi again, As a consequence, the selection of transports to communicate from a client to a server is a manual administrative action. An automatic fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- bidding attacks on the peer communication. [BA] If a fixed shared secret radsec is used alongside fallback to RADIUS/UDP, that seems more like a MUST NOT!! That paragraph was also brought up in the AD review. It was not meant in the way you perceived it; please see the thread of the AD review of this document for an extensive explanation how it was really meant. My working copy has the following text in Security Considerations now: If peer communication between two devices is configured for both RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using shared secret security),and where the RADIUS/UDP transport is the failover option if the TLS session cannot be established, a down- bidding attack can occur if an adversary can maliciously close the TCP connection, or prevent it from being established. Situations where clients are configured in such a way are likely to occur during a migration phase from RADIUS/UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker can reduce the security of the packet payload from the selected TLS cipher suite packet encryption to the classic MD5 per-attribute encryption. The situation should be avoided by disabling the weaker RADIUS/UDP transport as soon as the new RADIUS/TLS transport is established and tested. Disabling can happen at either the RADIUS client or server side: o Client side: de-configure the failover setup, leaving RADIUS/TLS as the only communication option o Server side: de-configure the RADIUS/UDP client from the list of valid RADIUS clients I hope that makes my intended statement clearer. If I'm not mistaken, IETF LC period is now over. I plan to produce a new -11 revision tomorrow to prepare the IESG review phase. It would be nice if you could let me know whether the changes I did in the document satisfactorily address your concerns. Greetings, Stefan Winter In any case, I take the point that the text is confusing for readers. While resolving the AD comments, I agreed with Dan Romascanu to reformulate this whole paragraph and move it to Security Considerations instead. I'll follow up with the new text later today. Section 6 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be able to accept connections from a large, not previously known, group of hosts, possibly the whole internet. In this case, the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer, i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks, just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs, checking critical extensions, checking subjectAltNames etc.) to prevent unauthorised connections. [BA] I'd recommend collecting this and other dynamic-discovery related material into a separate section prior to 3.1. Moved out of the document, to go into dynamic-discovery. Appendix C. Assessment of Crypto-Agility Requirements The RADIUS Crypto-Agility Requirements (link to RFC once issued here) defines numerous classification criteria for protocols that strive to enhance the security of RADIUS. It contains mandatory (M) and recommended (R) criteria which crypto-agile protocols have to fulfill. The authors believe that the following assessment about the crypto-agility properties of RADIUS/TLS are true. [BA] The Crypto-Agility RFC is now published so you should reference that. Done now in my working copy. Thanks for this extensive review, much appreciated! Greetings, Stefan Winter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [radext] Review of draft-ietf-radext-radsec
Hi, If peer communication between two devices is configured for both RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using shared secret security),and where the RADIUS/UDP transport is the failover option if the TLS session cannot be established, a down- bidding attack can occur if an adversary can maliciously close the TCP connection, or prevent it from being established. Situations where clients are configured in such a way are likely to occur during a migration phase from RADIUS/UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker can reduce the security of the packet payload from the selected TLS cipher suite packet encryption to the classic MD5 per-attribute encryption. The situation should be avoided by disabling the weaker RADIUS/UDP transport as soon as the new RADIUS/TLS transport is established and tested. Disabling can happen at either the RADIUS client or server side: o Client side: de-configure the failover setup, leaving RADIUS/TLS as the only communication option o Server side: de-configure the RADIUS/UDP client from the list of valid RADIUS clients I hope that makes my intended statement clearer. [BA] My issue is the use of a well known shared secret with RADIUS/UDP. This could be fixed by requiring that a server supporting RADIUS/TLS MUST check for a RADIUS/TLS connection before allowing use of the well known shared secret. Ah, I see. The spec does not mandate a fixed well-known shared secret for RADIUS/UDP at all. It only specifies that when TLS transport is used, security is provided on the transport layer, so the shared secret that used to protect the RADIUS payload is useless is set to this fixed term. When using RADIUS/UDP, the shared secret is still chosen by the administrator by configuration. Would it help to clarify the first lines to read: If peer communication between two devices is configured for both RADIUS/TLS transport (i.e. TLS security on the transport layer, shared secret fixed to radsec) and RADIUS/UDP (i.e. shared secret security with a secret manually configured by the administrator), and where the RADIUS/UDP transport is the failover option if the TLS session cannot be established, a down-bidding attack can occur if an adversary can maliciously close the TCP connection, or prevent it from being established. Just to make sure people realise that RADIUS/UDP security is untouched by this spec? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [radext] Review of draft-ietf-radext-radsec
suggestion of using Accounting-Response + Error-Cause. It may be the adequate thing to do since this specification is going for Experimental only. In the long run though, I think this solution is inadequate; if Accounting-NAK signalling is to be fixed, it should be fixed properly (i.e. on a per-packet basis) for all transports, not just this one. Maybe by updating 2866 with a consistent use of Error-Cause, or maybe by adding an Accounting-NAK packet type, analogous to the dynauth NAKs. It is definitely a useful thing to work on; but it's not for the RAIDUS/TLS draft to decide. That would need a wg chartered item (luckily radext is discussing rechartering right now; this might be worthwhile to include...) Please let me know if you'd prefer the Error-Cause patch to be in this spec; I'll do as you say :-) I promised my AD to publish the -11 revision for IESG review later today; if our conversation didn't converge until then, there can always be a -12. Probably necessary after the IESG review anyway :-) Greetings, Stefan Winter ___ radext mailing list rad...@ietf.org https://www.ietf.org/mailman/listinfo/radext -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
Hi, ... when the support people for a fairly well-established telco haven't even heard of IPv6, it's hard to believe that it's going to be available anytime soon. [multiple people essentially reporting the same] At this point in time $ISP has no immediate plans for implementation. I would say it's about time reality finally settles in. My reality is that I switched to an ISP who openly announced native IPv6 support in their offering in 2007. Up and running since then, and when I had trouble setting up the IPCP+IP6CP in the same PPP channel in IOS, I wrote them an email on a Saturday, and got a config snippet back an hour later, as part of their standard customer service. That ISP operates nation-wide and uses IPv6 as a marketing instrument to get techies to subscribe. For a price of converted 15 USD per month. That's in Germany though. Apparently, realities differ depending on where you are. Greetings, Stefan Winter Keith Moore wrote: Meanwhile, 6to4 continues to work just fine for me. So please explain again why it isn't premature to discourage a valuable transition mechanism? On that one I agree with Keith; where's the rush? Although imperfect, 6to4 was an obvious path and its demise would be the failure of the IETF, following a long list of things that have been killed prematurely. Ned wrote: Anyone who doesn't believe we have a major marketing problem here isn't paying attention. Hmm that is a point of view. You think you have a solution (IPv6) to what you perceive to be a problem (shortage of IPv4 addresses). However, some ISPs (and some other companies) do not consider it a problem, but a blessing. What the IPv4 shortage does is that it prevents new large players to enter the field, while allowing existing players to continue to do business as usual. As the shortage as been predicted for a decade, some (not all) have stockpiled addresses and are now reaping the benefits. In business, this situation is worth solid gold: it's called a monopoly. I'm fat and happy, and I want it to continue. In this case, it's even better: companies who benefit from it can argue that they are not the ones who created the monopoly, it was a built-in limitation of the system as created. Some may not like the parallel, but we have failed the IPv6 migration the same way we have failed the war on drugs. A while ago, there was this thing called the Tier-1 cartel. As originally designed, a very elusive club, with almost no way in and absolutely no tears when a member gets de-peered. Some have said that the cartel has failed as a system (due to a large number of multilateral peering agreements and other factors). But now what we have is a much larger number of largely unorganized but sharing the same goals entities: those who already have IPv4 addresses. It's even worse. When a resource becomes scare or limited, the big picture is not how much of it is available, or how much it costs. The big picture is how much of the market one does control. Now we are in the situation where everyone and their sister own a piece of the pie, and as long as the price of the pie keeps going up, they're going to cling to it. On top of the marketing problem you mentioned, you have a bigger one: there are many, many organizations out there that, even if you paid them to deploy IPv6, would not. Because IPv6 is a territorial threat to them. While the new or wannabe players would like the extra address space, the sad truth is that the already establish players don't like newly open spaces and prefer the territory control that comes with owning a piece of a limited land space. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
Hello, You appear to be able to browse the IPv4 Internet only. You will not be able to reach IPv6-only sites. Please can some one visit http://test-ipv6.com/# and give me more explanation on the displayed result? That message is quite clear, isn't it? You use an Internet Service Provider which only supplies you with IPv4 connectivity. If you want to visit a website which only supports IPv6, it will not work. The test website can be reached on both IPv4 and IPv6. So it can tell you: you came here via IPv4, and didn't manage to get here via IPv6. So there is no working IPv6 for you. Stefan Kind regards, Otunte Otueneh ISOC Nigeria Chapter On Fri, Jun 10, 2011 at 7:32 AM, Stefan Winter stefan.win...@restena.lu mailto:stefan.win...@restena.lu wrote: Hi, ... when the support people for a fairly well-established telco haven't even heard of IPv6, it's hard to believe that it's going to be available anytime soon. [multiple people essentially reporting the same] At this point in time $ISP has no immediate plans for implementation. I would say it's about time reality finally settles in. My reality is that I switched to an ISP who openly announced native IPv6 support in their offering in 2007. Up and running since then, and when I had trouble setting up the IPCP+IP6CP in the same PPP channel in IOS, I wrote them an email on a Saturday, and got a config snippet back an hour later, as part of their standard customer service. That ISP operates nation-wide and uses IPv6 as a marketing instrument to get techies to subscribe. For a price of converted 15 USD per month. That's in Germany though. Apparently, realities differ depending on where you are. Greetings, Stefan Winter Keith Moore wrote: Meanwhile, 6to4 continues to work just fine for me. So please explain again why it isn't premature to discourage a valuable transition mechanism? On that one I agree with Keith; where's the rush? Although imperfect, 6to4 was an obvious path and its demise would be the failure of the IETF, following a long list of things that have been killed prematurely. Ned wrote: Anyone who doesn't believe we have a major marketing problem here isn't paying attention. Hmm that is a point of view. You think you have a solution (IPv6) to what you perceive to be a problem (shortage of IPv4 addresses). However, some ISPs (and some other companies) do not consider it a problem, but a blessing. What the IPv4 shortage does is that it prevents new large players to enter the field, while allowing existing players to continue to do business as usual. As the shortage as been predicted for a decade, some (not all) have stockpiled addresses and are now reaping the benefits. In business, this situation is worth solid gold: it's called a monopoly. I'm fat and happy, and I want it to continue. In this case, it's even better: companies who benefit from it can argue that they are not the ones who created the monopoly, it was a built-in limitation of the system as created. Some may not like the parallel, but we have failed the IPv6 migration the same way we have failed the war on drugs. A while ago, there was this thing called the Tier-1 cartel. As originally designed, a very elusive club, with almost no way in and absolutely no tears when a member gets de-peered. Some have said that the cartel has failed as a system (due to a large number of multilateral peering agreements and other factors). But now what we have is a much larger number of largely unorganized but sharing the same goals entities: those who already have IPv4 addresses. It's even worse. When a resource becomes scare or limited, the big picture is not how much of it is available, or how much it costs. The big picture is how much of the market one does control. Now we are in the situation where everyone and their sister own a piece of the pie, and as long as the price of the pie keeps going up, they're going to cling to it. On top of the marketing problem you mentioned, you have a bigger one: there are many, many organizations out there that, even if you paid them to deploy IPv6, would not. Because IPv6 is a territorial threat to them. While the new or wannabe players would like the extra address space, the sad truth is that the already establish players don't like newly open spaces and prefer the territory control that comes with owning a piece of a limited land space. Michel
Re: How to pay $47 for a copy of RFC 793
Hi, Today if you're an IEEE type, and you wonder where to find RFC 793, or you're wondering what RFC 793 is about, and you look it up in IEEE Xplore, the online library that all electrical engineers use, and that their employers have site subscriptions for, you'll find ... nothing. Yes, you can find it in Google, but Google isn't a particularly good place to look for engineering papers. Xplore is. RFCs aren't in the ACM Digital Library, either, same problem. Nor is it in Google Scholar, which is generally where I look first. As a KDE user, I use the incredibly short shortcut of typing Alt+F2 and then rfc:793Enter (which redirects to http://www.ietf.org/rfc/rfc793.txt, not the GED hardcopy reseller :-) ) But maybe an IEEE type (whatever that is) doesn't use KDE. Or any kind of search engine that would yield the document in a fraction of a second. Or the internet at all? Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
Hi, Windows 7: enabled by default. Mac OS: enabled by default. Linux: whatever your distro does. I fail to see your point. Windows XP: disabled by default. Has been sold on the majority of Netbooks well into 2010, and Netbooks were 1/3rd of the PC sales. By the time end consumers feel an actual *need* to run IPv6, popular computer magazines will have the hot, new, hacker trick 'cmd' - 'ipv6 install'. But by that same time, people will probably not even remember the acronym XP. Hopefully so, for all of us :-) IPv6-capable beta firmwares for Fritz DSL-routers exist only for the two most recent models 7390 and 7270(v?). Other models (like the 7112/7113) or 7170, 7150) do *NOT* have sufficient resources to run IPv6 -- their flash memory is close to full as well as their RAM when they're running. So you need to buy new IT equipment every n years, where n is by preference (for the vendor) a low number? I'm shocked. BTW, switching your DSL contract after the 2-year-handcuff of your favourite operator will give you a new model for free. Stefan -Martin -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
Hi, Huh? Hardly anyone support IPv6 these days. Sony KDL40*X70* internet-enabled LED-LCD-TV, 2010, IPv4-only (bought 7/2010) My TV is bought 2009 and doesn't have any internet at all. And I don't care (much). It's a TV. Of all my gadgets, the TV is on my lowest priority for getting an IPv6 connectivity. Western Digital MyBookWorld2 HomeNAS, 2009, IPv4-only I don't mean to criticise your buying decision, but if you are so serious about IPv6 connectivity, why didn't you just buy a QNAP device? Comes with IPv6 just fine. Nintendo WII appears to be IPv4-only I do mean to criticise your buying decision: Playstation rocks :-) No, it won't give you IPv6 either; but it gets close to the TV argument. Probably my PS3 and TV will be dead (or administratively obsoleted) before I get headaches about them not reaching IPv6-only Firmware Update services etc. - because these devices still do dual-stack just fine. most home users in Germany can not even get IPv6 from their ISP, even when they had an IPv6-capable DSL-router. Excuse me, but this is completely 1990s argumentation. I have native IPv4+IPv6 with a commodity DSL provider since years. 2006, IIRC. And my own /48 with it. And the operator works Germany wide. With reasonable costs; my flatrate costs 9,50 EUR per month (though that's a legacy tariff, you can't order it any more). If you want IPv6, just go order it. I keep hearing this very argument over and over again - and it is simply not at all true; at least not in Germany. I'm not affiliated with the provider, other than being a satisfied customer: http://www.titan-dsl.de What capabilities there are available on the internet backbone or what could be enabled on newer operating systems by sophisticated end users doesn't matter much, if most of the internet-enabled end user equipment, that is being sold to consumers, is still IPv4-only. Windows 7: enabled by default. Mac OS: enabled by default. Linux: whatever your distro does. I fail to see your point. What we desperately need is factory-enabled transparent internetworking on all _NEW_ networking equipment and internet-enabled gadgets and appliances. As long as IPv4 and IPv6 are seperate worlds the hen-and-egg stalemate is going to continue. And the useful lifetime of all brand-new IPv4-only equipment that is produced by the electronic entertainment industry is about 5-15 years. The main point that needs attention is router equipment, IMHO. There's a Fritz!Box beta firmware for IPv6 right now; when it's final, pushing that out will fix the deployment of IPv6 for most of Germany (as they happen to be quite popular there). Dates are arguable, but: I suspect it will be + 15 years before content providers will switch to IPv6-only. If they do so before, this will reduce the useful lifetime of your already-bought electronics a bit. Hooray for the industry: they can sell new stuff to you then. That kind of thinking is probably not what you as a customer appreciate, but it's just fine if seen from the other side :-) Stefan -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dime-rfc3588bis-25.txt (Diameter Base, Protocol) to Proposed Standard
Hi, I was surprised to see the line No IPR declarations were found that appear related to this I-D. in the message from ietf-announce. Its predecessor, RFC3588, has a filed IPR disclosure from Nokia, see https://datatracker.ietf.org/ipr/323/ A very long time ago, I looked into the patents in question, and they seemed to be related to the T-Bit (Diameter message command flag for potentially re-transmitted message). Page 35 in 3588bis still contains the T-Bit. As a naive non-legalese person, I would think that the same disclosure that applied to the T-Bit in 3588 also applies to the T-Bit in 3588bis then. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
Hi, I was living in France in spring 2005 when the chip and pin systems went live there. There was a very short period where cards without chip and pin did not work. Two days later, facing the inability to take money from foreigners, signature-based transactions were back. Sometimes (including in the UK) the shop-owner may sigh in a dramatic way as they reach for the pen, but money is money! ... The more tricky part are cases where there's nobody around to check a signature (ticket machines in Stockholm come to mind). While we are on anecdotal notes on the b0rken CC system, here's one from Germany: Signature-based CCs were - and are - rather popular here. The Chip+PIN system was introduced anyways, which is arguably a good thing. My bank wrote me a nice letter that Chip+PIN had to be put on my new card, but to ensure that I can use the card in the more convenient (WTH?) way of signing, it had been configured to offer POSes both options, but defaulting to signature. This makes sure that a) I use signature next to everywhere, which makes me forget the nevertheless existing PIN b) if some POS understands enough handshaking to choose between the two and use Chip, I'm lost because I forgot it c) if some POS insists on Chip+PIN but does not understand enough handshaking to recognise that there is more than the default sig method on the card, I won't get service. Due to that, I can not use any automatic-payment refueling stations in Luxembourg, nor rent a bike (Veloh!) in Luxembourg City. Or train ticketing machines in the UK. I'm delighted. Thanks, financials! That's it for the rant of the day, happy Easter! Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
Hi, (ah, flamewars! My favourite! :-) ) Can't you notice fancy tool of you have wrongly translated a character in univerval. ?Any of quoted message, even though the original message by Martin Rex is pure ASCII. That is, two consequetive space charactersbefore Any is translated to a space character and something else, which is not legible to me. The converted message displayed perfectly for me (no question mark, but a non-breaking-space). That is because I use a standards-compliant mail reader which a) figured that the message encoding for Tim's message is ISO-8859-1 b) the character in question is listed in ISO-8859-1 as NBSP c) consequently displayed a NBSP for me. If your mail reader displayed something else, it is either misconfigured or broken. Please do not use your misconfiguration or broken software as an argument why using a beyond-ASCII character set is a bad thing in itself. Instead, either configure your product of choice to respect the advertised encoding, or complain to the vendor of your product of choice to fix their software. To get to the marginal correct point in your rant above: you may consider it rude by Tim that he mis-quoted the original post, and did some editing - even though the editing is not even visible. Whether or not that alteration of the original text upsets you or not is entirely your own thing, of course. It doesn't contribute very much to the discussion on character sets for RFC documents though. You have successfully demostrated that, beyond ASCII, even the simplest character handling is impossible. No, you have successfully demonstrated that the webmailer you are using is doing a bad job. (And I can easily say that in this case, because for an NBSP there is not possibly an excuse But I don't have a font which would contain this character - NBSPs are a standard feature of every web page, and a webmailer in particular needs to know how to handle that ) Before saying something about long history of confusions and frauds on internationalization, please don't convert someone else's pure ASCII message into something else. Conversions happen daily in countless formats. Your mail has been archived in the IETF's mailing list archive for ietf@ietf.org, and will be displayed, behold, on a *web page*. Fancy HTML tags around it. different font sizes for the headline. Does that upset you? If yes: even the IETF web archive does a better job at displaying your mail than your mail agent of choice. If you visit the following link, you'll see Tim's message on the IETF web archives. Note the perfectly rendered space instead of a question mark. http://www.ietf.org/mail-archive/web/ietf/current/msg60578.html (if you still see the ? instead, read above paragraph about misconfigured or broken software) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
Hi, As usual, the discussion of ASCII plain text versus beyond-ASCII plain text has been mixed up with the essentially unrelated discussion of plain text versus another format. +1 Stefan Martin Rex mrex at sap dot com wrote: Unicode characters are also a Royal PITA in specs, because they're non-discussable. There are extremely few people who can recognize all unicode codepoints from their glyphs (and a number of them can not be distinguished by their glyphs), and even worse, most machines/environments do not even have fonts to display glyphs for most of the unicode codepoints. The fact that Latin A and Cyrillic А and Greek Α look the same is not a reason to stick with only 95 printable characters. RFCs are not spoofing targets. The fact that most systems cannot display most of the unicode codepoints is irrelevant, because most English-language texts (like RFCs) use only characters in a small and well-known fraction of the Unicode code space. You might expect an RFC to contain non-ASCII characters like á and — that are part of a well-known and widely used subset like WGL4. You would not expect it to contain Egyptian hieroglyphs or Vai syllables or domino tiles. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Visas and Costs
Hi, Okay, so one advantage of having a meeting in the PRC is that the majority of participants (including US and Canadian ones) who can normally travel almost anywhere without VISAs will have to experience some of the pain of getting a VISA. You may have meant this in a sarcastic way, but it very literally *is* an advantage: it may cure some of the U.S. IETF participants who usually hand-wave away the visa issue of non-U.S. participants in a U.S. venue as can't be that bad, stop whining. It is always good to see the other side. Makes for a better discussion ground. (Disclaimer: I was not one of the people needing a visa. But I can have empathy for other beings.) Greetings, Stefan Winter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Hi, You're heading into new territory, here. Right now IETF documents are written in English and they're If you allow a bit of nitpicking here: they cannot be written in all the labels the English language has to offer, and thus they can only be written in a *subset* of English. So a devil's advocate (which I absolutely don't mind playing here) could say that the restriction to ASCII *prevents* expressing oneself in the full bouquet of English language; unfortunately, English language is mandatory for IETF documents. So, staying with ASCII would require a reformulation for IETF language from English to English words which can be expressed in ASCII encoding Example? Naïve is a perfectly valid English word. (If your mail reader doesn't display this correctly: that's an i with two dots on top instead of one) Likewise is coup d'état an English word (e with accent). All loan words from French, but nontheless English words. http://en.wikipedia.org/wiki/Naive http://en.wikipedia.org/wiki/Coup_d%27Etat At least the first one has been used in an I-D from the IAB very recently (http://www.ietf.org/internet-drafts/draft-iab-idn-encoding-00.txt). It used the alternative spelling with a normal i; the other spelling was obviously impossible for the reasons we are discussing in (parts of) this thread. Maybe the author wanted to use that alternative spelling anyway, but maybe he was forced to use it even though it hurt his eye and he is now drowning in grief over the butchering of language he was forced to execute in order to publish his work. We will never know for sure; unless of course the author tells us about his feelings on this list :-) Let's give ASCII its long-overdue coup de grâce ( http://en.wikipedia.org/wiki/Coup_de_grace ). Greetings, Stefan Winter displayable on a wider variety of hardware than HTML is. As I mentioned in the mail to which you're responding, I think the choice of formats tends to support more openness and accessibility. I think you're implicitly arguing that that's not the right tradeoff, and frankly I think it's exactly the right tradeoff, myself. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
Hi, What I hear in these discussions can get translated into a lot of it would be nice and little if any it is essential that. Changes to existing procedures tend to get driven by it is essential that, which is my point. A working group saying that the existing format restrictions are severely hindering their work would count for a lot here. I'll have a go at it (I am not a working group, but I hope you allow me to express my opinion anyway). Plain ASCII makes work on drafts which deal with internationalisation very hard. I have just uploaded a draft with an example second-level domain containing the German small u-Umlaut [U+00FC] as input to an algorithm. Sorry, in fact the draft did of course *not* contain the umlaut. I had to escape it with the [U+00FC]. Writing that impairs the readability and understandability of the example quite a bit since the input on paper is not the same as the actual input. This is, IMHO, severely hindering work. If merely expressing oneself *about* i18n problems properly is impossible, I'm not really surprised that internationalisation is perceived as hard and cumbersome. (It's hard and cumbersome enough without these restrictions already anyway.) Unicode is there for a while already and I think switching to any kind of format that supports international character sets is essential. Pick any format you like, as long as it allows people to express their problems and solutions without ugly hacks (read: as long as it supports the full set of Unicode - not just the first 127 characters). Greetings, Stefan Winter P.S.: a2ps never failed on me for producing 2-up, nicely framed and properly page-breaked printer output. -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Results from the Federated Roaming BBoF
Hi folks, this is a short summary of the Federated Roaming BBoF yesterday evening. My two Guinness hopefully left enough brain cells intact for this to be a complete report, but in case not: everybody who was there, please complete the pieces that I may have missed. RadSec -- After an introductory explanation of our deployment scenario in eduroam - aggregation of independent administrative domains (universities) to a central national proxy, and further aggregation of nationals into a continental proxy - we figured that at least in this particular use case, there is a good reason for a reliable transport, but no need for fancy Diameter features - especially since eduroam lacks commercial interest, i.e. accounting. In the course of the discussion, it turned out that other people feel the exact contrary need: Diameter over UDP (reported by Avi Lior). Interestingly enough, there were also use cases in the Diameter area that would require proxy hierarchies. It was interesting to see that both of the protocols provoked the same concepts of aggregation hierarchies in certain use cases. There was also an agreement that apparently none of the two protocols is superior to the other in all aspects, and a deployer would need to make his choice. In the end there was a rough agreement of let all the AAA transports have all the transport profiles they think they need, but the ultimate decision about that would need to be taken in radext on Friday. EAP error reporting --- Basic problem statement: if an EAP session can not be established or is interrupted prematurely, there is no good error reporting mechanism back to the supplicant+user. Avi confirmed that this is not only a concern for eduroam, WiMAX deployments see the same need. It would be good to have a reporting mechanism in EAP preferably (for the WiFi case, having one in 802.1X would also do, but EAP would be the more general solution). Binding layer 2 authenticated entities to layer 3 addresses --- Lawful interception is one of the drivers for that, current approaches to it are snooping DHCP traffic (as discussed on int-area before the BBoF). Having a clean solution here would be desirable. Stig's approach from the mailing list (distributing keys to supplicant within EAP and DHCP server via some other mechanism to bind the leased IP address to the entity was mentioned. Stig wasn't at the BBoF but later came up with a pretty sonsistent idea. He is going to write an I-D about it. (Note from self, not discussed in meeting: It is unclear though how this works with IPv6. Relying on DHCPv6 would need to disable stateless auto-config, and IPv6 Privacy Extensions wouldn't work any more) EAP fragmentation - A report on EAP-TLS usage in eduroam came as a surprise to most participants: I had to report that EAP-TLS in the international roaming case does *not* work more often than it does. We have tracked down the likely causes to a) UDP fragmentation [authenticator adds lots of RADIUS attributes to the raw EAP data, and with EAP-TLS the EAP chunks are often = the link-layer MTU already, resulting RADIUS packet is then often MTU between authenticator and AAA server] When staying local, chunk sizes of EAP can be tweaked to make stuff work, but when roaming to an unknown network with unknown infrastructure, this gets difficult and would have to be done at end-user side, i.e. it exceeds John Doe's capabilities and can not be considered a usable solution. Another possible cause is packet reordering and firewalls that then discard the incoming fragment because there's no observed previous fragment. We think that TCP as a transport (RadSec) could help mitigate that. There are no hard numbers and facts to prove that yet though. In any case, for plain RADIUS deployments, a max-desired-EAP-chunk discovery mechanism would be interesting. That should be pretty much it. May the force be with you, Stefan Winter ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
BBoF on Federated Roaming: Update
Hello, the BBoF on Federated Roaming issues is still scheduled for Wednesday, 20.00 hours, shortly after the plenary. The number of responses so far was low enough to warrant ad-hoc location determination. Let's meet at the registration area. As a rough indication what to expect: I'm almost 2m tall, and still in my late 20s (counting the days :-( ). Also I'm probably the most nervous person in the vicinity since this is my first BBoF-style thing :-) The easiest choice from the registration area will probably be the Champions Bar on the ground floor, but I'm open to better ideas at any time. Greetings, Stefan Winter ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Discussion about Federated Roaming
Hello! My name is Stefan Winter of the National Research and Education Network in Luxembourg, RESTENA. We are an ISP for academia and take the lead in research and development of a global academic wireless LAN federated roaming consortium: eduroam. This is based on EAP and 802.1X exclusively. In the course of development, prototyping and rollout of eduroam, we have discovered that some areas of the relevant standards required some tweaking or workarounds. After following IETF work for some time, we also saw that some of the efforts exclude roaming use cases from their agenda. So far I've heard that we are by far the biggest federated 802.1X roaming consortium at all, and I wonder if we are the only ones seeing some items that could use a second thought when considering roaming between independent administrative domains. I will be at IETF71, and would like to invite anyone who is interested in federated roaming scenarios for an informal get-together to exchange ideas. I was planning to do this on Monday evening, at a location that is still TBD, I'll follow up. Below I've put together the most prominent items that are on our radar right now to give you a glimpse of the issues we in eduroam are dealing with. The most prominent issue is the uneasy fact that RADIUS doesn't provide a reliable transport and only basic security, while Diameter has no implementations and NAS support in the wireless LAN area. With an EAP conversation requiring multiple, usually around eight, roundtrips, and a packet path that may literally span the whole world, this is a major concern. It also didn't particularly help that in a recent discussion on dime, it was stated that Diameter doesn't offer significant advances regarding roaming compared to RADIUS. We tried to mitigate this by proposing RadSec, RADIUS over TCP+TLS [1], and are pursuing this in the radext wg right now. Another thing is that we have no sufficient signalling mechanism to reach the end user if the 802.1X login couldn't be completed because of an intermediary RADIUS proxy being down - due to the lack of possibility to provide error messages in the 802.1X protocol, most supplicants provide the unhelpful advice that Probably the password is wrong, which is wrong and generates user frustration. Some kind of hijacking the EAP conversation by the last responsive proxy to inject EAP-Notifications would be needed probably, but this is not thought through in its entirety yet. I'm aware that there is a security argument: not disclosing the reason for a failure may make attacks more difficult, but still: it would then be desirable to at least have the *option* of providing the info - right now it is impossible. Then, encapsulating EAP in RADIUS may sometimes lead to RADIUS packets being so big that they have to be fragmented - not a conceptual problem, but a practical one, because out-of-order fragements, or even even in-order UDP fragments generate problems on unclever firewalls more often than not. Especially EAP-TLS, where both server and supplicant need to send large amounts of (certificate) data turned out to be a real challenge. A draft about that problem and a sketch of a possible solution is in the works. Another thing that bugged us about RADIUS is the inability to contact new auth servers on the fly, for example when a new user realm is observed. So far, we stacked together RADIUS servers in a realm-based aggregation hierarchy. A better approach, in combination with the TCP+TLS nature of RadSec, would be to use a dynamic lookup mechanism (e.g. DNS NAPTR/SRV) that allows to discover the authoritative home server for a user's realm and to verify that server's eligibility by examining the certificate. This is a concept we will try out in semi-production use in eduroam soon, but it may have implications also out of the eduroam community, since it will allow arbitrary service providers to create an authentication fabric very easily on the technical side - making the *paperwork* of bootstrapping a roaming consortium the only big challenge. We have been looking at the work of the NEA wg with a bit of concern, since its charter excludes the federated roaming case deliberately. For example, putting posture information into EAP will always convey the posture info to the home server, while it is the service provider that needs the posture information to make its admission decision. We understand though that there is work going on to make the use of NEA roaming-agnostic, which we would very much like to see. Finally, there is a more exotic area in connection to roaming scenarios: converging roaming on the network layer (802.1X+EAP) with Single-Sign On on the application layer (SAML et al), with the ultimate goal that using a set of credentials to log into the network also generates an application layer token to use for signing into services - without the need to re-authenticate. I realise that some
