Re: [radext] Comments on draft-wierenga-ietf-eduroam-00

[Klaas Wierenga <[e-mail]>]

On Mar 28, 2013, at 11:43 PM, Jim Schaad <[e-mail]> wrote:

Hi Jim,

It took a while, but we just submitted version 01 (http://www.ietf.org/id/draft-wierenga-ietf-eduroam-01.txt) that addresses your comments per below as well as a bunch of other changes, like a paragraph on dynamic discovery and privacy considerations.

Thanks again!

Klaas (and Stefan, Tomasz)

===

> Remember you asked for it.
> 
> I am CC-ing the radext list for completeness not because I believe this
> should be a radext working group document.
> 
> 1.  It is not clear to me that the use of RFC 2119 language is appropriate
> to a document that is describing what the current design is.

Hmm, I understand the point, but we use that language on purpose in our policy docs as well, perhaps a clarifying text to that extent?

Proposed text: "Note: The policy that eduroam participants subscribe to expresses the requirements for participation also in RFC 2119 language.
"

> 
> 2.  Introduction: Suggest that the introduction should give a layout of the
> document as well.   Specifically there are two ways to organize the second
> half of the draft <problem, solution> or <problems><solutions> and it would
> be good to set expectations of this upfront.

OK, proposed text: "First this memo describes the original architecture of eduroam. Then a number of 
   operational problems are presented that surfaced when eduroam gained wide-scale deployment.
   Lastly, enhancements to the eduroam architecture that mitigate the aforementioned issues 
   are discussed.
"

> 
> 3.  Given that RFC 6614 and 6613 are experimental - do you want to say /IETF
> standardization efforts/?

I think we can argue that it is a standardization *effort* even if it has not led to formal standardization yet

> 
> 4.  Section 1.3 - Who has to be able to identify users? Just the IdP or the
> NAS as well?  

Proposal: "The access provider (SP) needs to be able to determine whether a user is authorized to 
   use the network resources. Furthermore, in case of abuse of the resources, there is a 
   requirement to be able to identify the user uniquely (the IdP). Lastly, it should not 
   be possible for a person to impersonate someone else or take over their identity."

> 
> 5.  what does it mean to either impersonate someone or to take over their
> identity?  If I give you my name and password it is possible for you to
> impersonate me.  This language should be tightened.

Text rephrased to: ""The access provider (SP) needs to be able to determine whether a user is authorized to 
   use the network resources. Furthermore, in case of abuse of the resources, there is a 
   requirement to be able to identify the user uniquely (the cooperation of the user’s IdP is required)."

> 
> 6.  Do you really want me to be able to access your network or are you going
> to provide a public network for me to be able to access and use?  It might
> need to be clearer what is going on.  The first implies a greater degree of
> identification that might actually exist.

Added: "Note: traffic separation between guest users and normal users is possible (for example through the use of VLANs), often desirable and widely used in eduroam."

> 
> 7.  I can see three different vectors of scalability - it might be useful to
> tease that out.  Users, Orgs providing access, Orgs hosting users.  Are the
> last two a one-to-one or not?  
> 

I think we address that further down

> 8.  For whom does it need to be easy to install and use - just clients or
> organizations as well?  Can it be hard for an org to setup and still be easy
> for clients?

added: "for both organizations and users"

> 
> 9.  In the paragraph on security, I don't understand the purpose of the
> first sentence.  This would tend to argue that secure is not an absolute
> design goal.  There may be a trade off, but that would be a design goal of
> usability which is separate.

changed to:  "It is important to have a system that strikes a good balance between ease of use
   and security. "

> 
> 10.  The goal is secure and privacy preserving - however there is nothing in
> the text about who the privacy is supposed to be protected from.  While I
> guess it could be the third part, that is hardly the limit of who one could
> wish for privacy to be protected from.  Do you care about privacy from the
> visited SP?  Should the IdP be able to know who the client is visiting?

We split security and privacy as follows:

“Secure
One important design criteria has been that there needs to be a security association between the end-user and their home organization, eliminating the possibility of credentials theft. The minimal requirements for security are specified by the eduroam policy. As an additional protection against user errors and negligence,  it should be possible for participating organizations to set their own additional requirements for the quality of authentication of users without the need for the infrastructure as a whole to implement the same standard.

Privacy preserving
The design of the system provides for user anonymization, i.e. it should be possible to hide user’s identity from any third parties including visited institutions.“

> 

> 11.  It is laid out that organizations should be able to set their own
> authentication structure.  Is there going to be a minimum security that is
> imposed on organizations by the eduroam federation?

addressed in the text addition above

> 
> 12.  Were any other options considered for the architecture?  If so why were
> they not used? 

added: "Three architectures were trialed: one based on the use of VPN-technologie (deemed 
   secure but not-scalable), one Web captive-portal based (scalable but not secure) and 
   802.1X-based, the latter being the basis of what is now the eduroam architecture."

> 
> 13.  Section 2 - If you read the ABFAB architecture document, I think we
> talk about three different trust relationships.  Two of which are
> "pre-existing" and one of which is established during the protocol.  

I think that is what is stated in the text: user-IdP, IdP-SP and the transitive trust between user and SP. Ah, I now see why there is confusion, adjusted text.

> 
> 14.  Going from the term type of trust to trust relationship does don't flow
> well.
> 

changed to "trust relation" everywhere

> 15.  The term establishment is potentially confusing in this location.  Are
> you talking about for a single event or initial establishment (i.e.
> introduction ) between the user and the IdP.

ack, removed the establishment phrase, it is not about introduction

> 
> 16.  Section 2.1 - I can understand that authentication uses EAP.  However
> how does it use 802.1X and not use RADIUS for authentication?   If 802.1x
> does anything other than carry EAP this should be covered.   Otherwise you
> should probably include RADIUS here as well.

I added "(carried over RADIUS)"

> 
> 17.  Section 2.1.1 ?? wireless networks MUST support WPA2+AES - What does
> this mean?  It is a requirement that all networks deploy this or merely that
> the hardware has the capability to use it?  If a network deploys both WPA2
> and WPA does that require that multiple SSIDs be used?  If so is there a
> naming convention that is documented for this usage type?

They MUST deploy WPA2+AES, they MAY deploy WPA for legacy reasons. The only SSID for both is 'eduroam' (given that one SSID can advertise support for both simultaneously), the idea is to over time phase out WPA (as was done previously with WEP)



> 
> 18. What are the security implications of not knowing who the SP is - since
> all SSIDs are "eduroam" it is not possible to distinguish from a user
> perspective which are not to be used.

added: Note: A direct implication of the common eduroam SSID is that the users cannot 
   distinguish between a connection to a home network and a guest network at another 
   eduroam institution (802.11-2012 does have the so-called “Interworking” extensions to make that distinction, but 
   these are not widely implemented yet). Therefore,
   users should be made aware that they should not assume data confidentiality in the 
   eduroam infrastructure.

> 
> 19.  Discuss the trade of for not always using "eduroam-foo" as the SSID

added: "The downside of the latter is that clients 
   will not automatically connect to that SSID, thus losing the seamless connection 
   experience."

> 
> 20.  Section 2.1.2 - What guidance is the federation giving on EAP methods -
> is that of interest to this document?

see the text under figure 1

> 
> 21.  What is the "policy with regards to security properties"
> 

changed to:  "as long as they adhere to minimal requirements as
   set in the eduroam policy (which change over time).", see also text under figure 1


> 22.  I don't understand the purpose of Figure 1 - It does not appear to be
> reference from the text in any way.  The picture would seem to be
> underspecified in that the specific protocols are not put any place (i.e.
> X802.1x)  and the term EAP tunnel is not introduced in any manner.  As with
> the ABFAB document I did like that it is not clear that the tunneled eap is
> not traveling directly between the host and the authentication server.
> 

I added: "As depicted in Figure 1, the use of a tunneled EAP-method creates 
   a direct logical connection between the supplicant and the authentication 
   server, even though the actual traffic flows through the RADIUS-hierarchy."


> 23.  Note that mutual authentication does not imply privacy.  If I
> authenticate with EAP-TLS and send both the server and the client
> certificates in the clear then I have mutual authentication however I have
> no privacy on identities.
> 

The sentence
“In order to preserve privacy, participating organizations MUST deploy EAP-methods that provide mutual authentication.”
should read:
“In order to preserve credentials protection, participating organizations MUST deploy EAP-methods that provide mutual authentication.”


> 24.  The term outer identity is problematic.  There is the EAP outer
> identity - and then there is the RADIUS user-identity attribute.  The
> routing is done on the later and it is generally (but not always) copied
> from the initial EAP method.  However not all methods will have a distinct
> inner identity.  Is there an identity that is transmitted on 802.1x that is
> used rather than the first eap name?

should be ok with the previous change?

> 
> 25.  When did you suddenly say than a TLS tunnel was required.  If this is
> true it should be stated someplace explicitly.  This is not a requirement on
> IdPs that was not there before.  

I don't think we do

> 
> 26.  Do you want to say that outer identities must be NAIs or not?

The current policy consciously removed RFC4282 as a normative name format because that RFC is somewhat broken. We will refer to the revised NAI document when it’s published; until then we helped ourselves by explaining that it needs to be @-delimited with a DNS-domain-like structure to the right. I wouldn’t use the term NAI these days, as it is highly debated in radext what exactly that *is* in the first place.

> 
> 27..  Section 2.2.1 - You just sprang a national server on me without
> telling me what it represents.   Are you assuming that all routing is two
> levels deep or  is there three and four level deep routing.  

The routing can be deeper than two levels. The smallest maximum depth from a leaf (SP, IdP) to the root is two: leaf, national, international. However, more intermediaries can come in; some countries have “regional” servers which add a node between leaf and national; and some of the nodes we consider leafs can also extend further (e.g. an IdP could have independent departments, all having their own RADIUS server).

I changed the wording slightly and added: "Note: In some circumstances there may be more levels of RADIUS servers, like for 
   example regional ones."

> 28.  Do you want to say at this point who is operating the national servers
> and root servers?   On what basis will they setup or remove shared secrets
> with organisations?

hmm, do you think this operational stuff should be in?

> 
> 29.  What are the trade offs of using [e-mail] vs @surnet.nl for
> the outer identity?

The empty left-hand side is the recommended format of RFC4282, but it has the downside of some supplicants or IdP servers choking over it apparently.

> 
> 30.  What, if anything needs to be said about the trust needed between the
> access points and the organization RADIUS server.  Is this under some type
> of protections?
> 

added “Note: The security of the connections between local wireless infrastructure and local RADIUS servers is a part of the local network of each SP, therefore it is out of scope of the document. For completeness it should be stated that security between actual access points and their controllers is vendor specific, security between controllers (or standalone access points) and local RADIUS servers is based on the typical RADIUS shared secret mechanism.”

> 31. Section 3 - Not all of the issues appear to be future problems that are
> expected.  This paragraph should be expanded to say that current operations
> have identified problems, in addition others are expected with an increase
> of …

changed text to: "While the hierarchical RADIUS architecture in the previous section has
  served as the basis for eduroam operations for an entire decade, the
  exponential growth of authentications is expected to lead to, and have in fact in 
  some cases already lead to, performance and
  operations bottlenecks on the aggregation proxies. The following sections describe 
  some of the shortcomings, and the resulting remedies."

> 
> 32.  Section 3.1 - I think the word you are looking for is deduced rather
> than deducted in many of these sentences.

ack

> 
> 33.  I have a slight problem with the fact that you are using down the
> authentication path since you have just told me that it is a tree and thus
> has both an up and a down component.  'Along' might be a better choice.
> 

ack

> 34.  I would not use the term proxy chain when looking at the length.  I
> would just say that the radius authentication chain contains more than one
> hop.   If there were no proxies then you have no problems, but in that case
> the proxy chain is 0 hops? 1 hop?  Not clear.

hmm, but the authentication chain refers also to the supplicant, the NAS etc., whereas this is specific to the RADIUS servers on the path

> 
> 35.  I assume that if a server which is believed to be "dead" sends you an
> authentication request then you would also know that it is now live (step 3)
> 

No, I don’t think that’s correct. Packet flows are always from SP to IdP, with replies coming back. It’s a directional graph. If you see something coming from the other direction, then that hop acts as an SP. It may well be that the SP function of a site is up, while it’s IdP function is not. It’s not good to expect that “the whole thing came back”

> 36.  One option that is not discussed here is the option of always flooding
> and never assuming anything but realms fail.  What are the operational
> problem with this approach.
> 

this is discussed in http://wiki.eduroam.cz/dead-realm/docs/dead-realm.html that we reference

> 37.  Presumably the use of TCP rather than UDP would also help this
> situation.  Since you seem to be talking about ways that can be used to fix
> this here.

yes, mentioned further down

> 
> 38.  Section 3.2 - ? reactively or retroactively?

changed the whole sentence to: "The ability to send Status-Server watchdog requests is only of use
    after the fact, in case a downstream server doesn't reply (or hasn’t been contacted in a long while, so that it’s previous working state is stale)."

> 
> 39.  You don't say how much improvements from section 3.1 would deal with
> this issue.  If you could get reliable - don't fail because I did not get a
> reply - does this help the situation in the event of no reply?

Also this is extensively discussed in http://wiki.eduroam.cz/dead-realm/docs/dead-realm.html

> 
> 40.  What would be the security implications of being able to inject an
> error code into the stream by a middle man?  Are they any worse than the
> injection of an access-deny?

What error codes are you referring to? Afaik RADIUS doesn't have any.

> 
> 41.  Do you need to talk about dropped packets in this context as well as
> dead servers?

All failover is implementation-specific, so it's hard to say anything for sure. In all
implementations I know, a series of packets need to get lost before a
server is assumed dead; the number is often configurable. So, just a bit
of packet loss is not something that creates problems in terms of
marking-dead. It merely increases time-to-auth for the request in
question, because the NAS needs to re-transmit this packet.

> 
> 42.  If 802.1x does not allow for returning errors.  Are you suggesting that
> the RADIUS servers would inject EAP packets in the event of failures or
> should this be handled by the NAS?

These happen on the first exchanged packet; an EAP-Identity from the client, but no conversation going on yet. That’s why the top-level servers send an Access-Reject *without EAP-Message* in their reply. Injecting EAP would be very evil!

> 
> 43.  Section 3.3 - You need to tell me what a ccTLD and a gTLD are

expanded acronyms

> 
> 44.  What are the "downsides" to routing based on insertion of new
> "national" servers that can talk directly to the org servers?   These
> servers would potentially need to be more intelligent - but it would
> restrict the places where tables need to be routed.  Was this considered?

Yes; administratively not wanted and operationally impractical. E.g. shared secret negotiation with that fake “national” server involves people from around the globe in their actual countries - language barrier etc. Also, these servers need to adhere to their respective *national* polciies, but RADIUS connectivity enforcement is at the fake national server, a third party. Also “who owns .xyz” (i.e. where is it located physically) is both a political question and one of performance (round-trip time varies significantly depending on how close you are).

> 
> 45.  I am not sure that I understand why doing an add of a new route would
> be especially error prone.  It seems that this should be easily fixable by a
> simple tool.  Are you ever removing this from the table - it seems that this
> would be overwhelmed by adds.  Are these mappings made at more than just the
> root level - that is not clear from the discussion although I assume it
> would be true.  

perhaps we are just more stupid than other operational communities ;-) 

> 
> 46.  Who are you imposing the recommendation on?  Is this a new 802.1x
> requirement for an updated draft?  If so is this really what you want - or
> do you want to be able to negotiate the L2 packet size all the way down?

ehm…

It is not a protocol recommendation - it's a call for implementations to make a sane
choice of size when crafting the packet.

The Framed-MTU attribute already provides the information of the L2 max
size on the supplicant link. The number of attributes (=bytes) added by
proxies is unknown and variant. I don't think a negotiation would work
reliably.

However…. thinking more about this, this is probably an issue that is overtaken by events…. 
This recommendation comes from back in the day
when we discovered that UDP fragmentation can kill auths if firewalls in
the middle discard UDP fragments (surprise!). Our reaction back then
was that we thought there's nothing we can do about those firewalls and need to adapt the protocol
sizes.
Today, we think that this approach was wrong. If people deploy
broken network equipment which unduly discards packets, then what they
need to do is FIX THEIR EQUIPMENT. And I believe that this has happened
in eduroam quite consistently. It's been a long time since I've heard
from serious EAP-TLS problems. And that's not because supplicant vendors
have listened and reduced the payload size for us (I much rather believe
they ignored us or simply were not aware of our existence) - it's
because internally in eduroam we got the message across that admins need
to watch their firewalls. Many NRENs for example include oversize packet
checks in their monitoring infrastructure.

So in summary we propose to remove the paragraph ;-)

> 
> 47.  For whom are they hard to diagnose? Are you just talking about users or
> are you talking about IT departments as well?  Are there recommendations on
> how to do this diagnosis?

Replaced last paragraph of 3.4 with: "Both of the previously mentioned sources of errors (packet loss, fragment discard) lead to significant frustration for the affected users. Operational experience of eduroam shows that such cases are hard to debug since they require coordinated cooperation of all eduroam administrators on the authentication path. For that reason the eduroam community is developing monitoring tools that help to locate fragmentation problems."

> 
> 48.  Section 3.5 - Are EAP MSKs used in this configuration?  If so then you
> have low level encryption on these and it could potentially be stolen and
> used.

No, no MSKs, but rather server certificates, and proper settings

> 
> 49.  It is not clear to me that using a pseudonymous client identifier for
> the client does much of anything to prevent linking to an actual client.
> You still can build a large mobility profile.

There are two issues here. We identify problems related to the privacy and essentially state that they cannot be easily rectified. Pseudonymous identifiers are better from identifiers that explicitly expose user’s identity. It is up to the IdP to balance between the lack of anonymity provided by EAP-TLS and the full credentials security. However the motivation for 3.5 is to show that these unavoidable flaws can be made less serious if traffic encryption is introduced. IThat is what we are trying to say.

> 
> 50.  You have not dealt with the issue for TLS of checking that the server
> certificate is still valid.  This is also not currently done.

True, this is a problem, albeit not specific to eduroam but EAP in general. I don't think there is any good solution to that problem yet (OCSP stapling?)

> 
> 51.  Have you brought up the concept of an EAP configuration meta data
> format in the EMU group?  It is about to close.

We brought it up at a AAA doctor’s slot, and were told the best place is likely opsarea/opsawg. We’ll go there with an I-D in one of the next meetings; not Berlin.

> 
> 52.  Is there a reason why you don't reference RADIUS-TLS at this point as
> this would deal with this issue to a certain extent.  I.e. no protection
> from the proxies but from eavesdroppers.

I hope that the introductory text explaining how we separated problems from potential solutions addresses this point

> 
> 53.  Section 4.1.1 - why is the translation not satisfactorily answered by
> NASREQ?

If a Diameter response is an Error response, it can’t be translated to RADIUS. NASREQ is silent what to do then - Access-Reject? Remain silent? Also, if the Diameter reply has an attribute >253 bytes, no way to convert it. The suggested way in NASREQ is to treat this as Access-Reject, which is not a satisfactory result. Actually, this one could go away with the extended attributes RFC.

> 
> 54.  The last pargraph of 4.1.1. should be the first paragraph of 4.1.2

ehm, it is intended as a segway into 4.1.2…

> 
> 55.  Section 5 - It would seem that placing the policy enforcement with
> Chargeable User Identity at the RADIUS server nearest the NAS - or at the
> edge of the organization, would make as much sense as placing it on the NAS
> itself.  This would allow for correlation between different access points
> and given a better idea of abuse on the network as a whole.  Thus using the
> servers that do this would solve the problem better.

If CUI support is built into the NAS then we have a lot more information on the NAS level. If CUI is not on the NAS but retrofitted in the server, then the server gets the same amount of information as before, but NAS does not get anything, therefore the first scenario is a lot more useful and should be promoted in the vendor community.

> 
> 56.  Section 5.1 - It may be also taken as evidence that you have no idea of
> what is going on as you have not identified the serious incident as being
> serious.

good point ;-)

added: "It could of course also mean that we lack the proper tools or insight into 
    the actual use and potential abuse of the service. In any case, many of the attack 
    vectors that exist in open networks or networks where access control is based on 
    shared secrets are not present, arguably leading to a much more secure system."

> 
> 57.  Section 5.2 - How does the fact that the home site is now going have
> the ability to block reflect back on the question of differences of opinion
> on if the action was abuse or not?  What type of protocol is setup for
> dealing with this type of request- is it automated, done by hand or through
> the infrastructure?

changed the last paragraph of 5.1 to "The first action in the case of an incident is to block the user's access to eduroam 
    at the visited site.  Since the roaming user's true identity is likely hidden behind 
    an anonymous/fake outer identity, the visited site can only rely on the realm of the 
    user. Without cooperation from the user's home institution, the SP's options are 
    limited to blocking authentications from the entire realm, which may be considered as 
    too harsh.  On the other hand, the home institution has only the possibility of 
    blocking the user's authentication entirely, thus blocking this user from accessing 
    eduroam in all sites. With eduroam becoming more and more global it can be 
    expected that differences of opinions in interpreting user’s actions may arise between 
    SPs and IdPs. It is the obvious right of an SP to provide guest access only under certain 
    conditions, when these conditions are violated by the user, the network access may be 
    blocked at the current site, however there may be situations where such a restriction 
    should only apply at a given SP and not eduroam as a whole. The initial implementation 
    has been lacking a tool for an SP to make it’s own decision of for IdP to introduce a 
    conditional rule applying only to a given SP. The introduction of support for 
    Operator-Name and Chargeable-User-Identity (see below) to eduroam will make both of 
    these scenarios possible."

that should address your point

> 
> 58.  Section 5.3 - Given that home servers are required to regularly churn
> CUIs, how does this affect the local accounting problems in terms of
> tracking and preventing people from abusing the system.  Can the home IdP
> simply deal with this issue by changing the CUI of an individual every time
> an abuse is reported?

While there is no REQUIREMENT for CUI churning, the CUI RFC does say:
"Furthermore, where a reference is used to a real user identity, it is recommended that the binding  lifetime of that reference to the real user be kept as short as possible."
It also says:
" The binding lifetime of the reference to the user is determined based on business agreements." 
The typical CUI usage scenario is within a charging environment where billing periods apply. eduroam does not have any billing, therefore it does not have a natural CUI lifetime either. 
Our implementation in FreeRadius does not address this issue at all. This may be a weakness on the implementation side, however adding this would vastly complicate things, requiring the server to keep track if validity periods. 
The suggestion that CUI should be changed each time an incident is reported would apply to a negligible number of cases and would not in any case increase the privacy of all users who are not responsible for any misconduct. Therefore is really not worth the trouble. Anyway, the eduroam policy currently states that the CUI value MUST stay constant.

we would prefer not to tackle this in this draft though…

> Random changes
> 
> s/Abfab/ABFAB/

ack

> s/in all continents/on all continents/

ack

> s/like for example/like/

ack

> s/alternative use/alternative uses/

ack

> s/foresaw/?????? - I am not sure what this sentence is supposed to say/

foresaw -> fore

> 
> Update reference to privacy terminology draft - it is now
> draft-jab-private-considerations

s/private/privacy, but ack