ITAC Meeting Minutes
July 16, 2009 4:00-5:30
Allen Board Room

  • Announcements & Meeting Minutes
  • Two-factor authentication - Craig Henriquez (ECAC), Klara Jelinkova, Rob Carter
  • DukeMail changes to minimize email blacklisting - Mark McCahill
  • Microsoft licensing agreement - Klara Jelinkova, Evan Levine

 
Announcements & Meeting Minutes

Terry Oas opened by asking ITAC members present at the June 4, 2009 and June 18, 2009 meetings if they had comments on the minutes. Terry encouraged ITAC members who spoke at previous meetings to review the minutes to ensure there contributions are accurately reflected.  Noting no objections to the previous minutes, Terry accepted the minutes and stated that they would be posted on the new ITAC web site.

Kevin Davis announced that TechExpo 2009 (http://techexpo.oit.duke.edu/), an event that joins central and departmental IT staff, is scheduled for Friday October 2, 2009.  The organizers will be requesting proposals by the end of July.  Any IT staff is encouraged to volunteer.

Kevin then announced that the ITAC web site would be migrating to the new Duke Services web template.  The URL will change slightly to http://www.duke.edu/services/itac/. The new site will have richer contact options.  In addition, the membership page will include links to members’ individual pages for more information.  Kevin added that the meeting minutes page will be modified to reflect the meeting date, location, and agenda on a single page.  Those descriptions will then link to the meeting minutes.  Kevin said that the meeting minutes will be searchable.  Tracy asked about the possibility of adjusting search parameters to reduce the frequency of previous ITAC minutes in search results showing up on Duke home page searches.  Kevin said he would take this feedback to the implementation team.

Dave Richardson asked what the scope of TechExpo is.  Kevin said that TechExpo has generally been a single day event where Duke University and Health System IT staff come together and participate in a series of presentations, network with peers, and professional development.


Two-factor authentication - Craig Henriquez (ECAC), Klara Jelinkova, Rob Carter

Terry said this topic originated from a conversation John Board and Paul Horner had with ECAC, the Executive Committee of Academic Council.  Academic Council is the campus’s primary faculty governance body.  ITAC is a subcommittee of the Academic Council.  Terry said that at John’s discussion with ECAC, some concerns were raised about the use of the NetID password to protect personal and medical information.  ECAC’s concerns produced spirited discussion with the steering committee, and one possible solution to assuage these concerns is two-factor authentication.  

Robert Wolpert noted that two-factor authentication is the principle that a user has two of the following to authenticate: something you know, something you have, and something you are.  He was concerned that the forthcoming proposal was not necessarily two-factor authentication but, rather, single-factor authentication repeated twice.  

Rafael Rodriguez said that no health records are protected through the NetID system.  Tracy added that personal information can be accessed with NetIDs through Duke@Work.  

Robert W. asked if one could get lab results online.  Rafael said that functionality is available through a patient portal for individuals who opt in and create a NetID-independent set of credentials.  

Craig Henriquez said before the ECAC meeting in question, someone had mentioned that medical records were now available online.  Craig had assumed NetID authentication was used as the front-end.  This led to the larger exacerbated state of the conversation.  Craig added that if someone had a single, unchanged password for many years that could now potentially access personal information without the person’s authority.  

Rafael reiterated that the accounts and passwords for the patient portal are fully optional and independent of the NetID account and password infrastructure.  John added that the overwhelming majority of ECAC members shared the concern raised at ECAC.  

Klara Jelinkova said that today’s discussion would avoid the topic of the password-sharing policy and delegation of privilege some applications provide.  For the purpose of this discussion, it is assumed that some people share passwords and some people do not. The team evaluated potential solutions on how to provide user-definable preferences based on their use case rather than forcing all groups to follow preferences that might not work for them.  

Klara said that in the two single-sign on demos to follow, the sample implementations take advantage of the ability to inject additional authentication factors into the logon process. For example, the authentication process could be modified to require a PIN, a card swipe, or key chain random string generation.  The demo uses a PIN because that is the easiest to model, she said. The second demo uses cell phones to issue PINs to users.  The important concept is that Duke has username and password today, but can leverage other authentication factors it defines.

Alvy Lebeck said two issues were raised, the level of access to certain services, such as health records, and the applicability of the Acceptable Use Policy (AUP).  He suggested that if the AUP is “out of sync” with how the Duke community operates, it raises the question of a need for an acceptable use policy, or at least to be adjusted properly.  John said that was the purpose of the ECAC discussion was to review the AUP.  

Klara said that her aim was to demonstrate possible technical alternatives.  Terry suggested that the applicability of the AUP might be an agenda topic for a future ITAC meeting.  Tracy said that moving towards two-factor authentication might be an intense process.  Klara’s mockup aimed to show what implementations might look like.

Rob Carter said the goal was to build “user selectable flexibility” into the authentication mechanism.  Rob demonstrated the ability for users to access a self-service application that allows users to manage their web application preferences.  In this example, the application would allow users to require a numeric PIN of their choosing in addition to NetID/password to access that application.  He highlighted the flexibility of the infrastructure to allow users to opt for different types of additional authentication beyond PIN if they existed.  

Rafael asked how the list of applications would be populated; i.e., which applications would be eligible to use this augmented authentication.  Rob said that application owners would be able to enable this service using Shibboleth.  Tracy said that OIT would need a Shibbed application desirous of enhanced authentication to be registered in order to be so eligible, though the application wouldn’t require modification to use the additional authentication (Shib would handle that.)  Billy Herndon asked about non-shibbed applications.  Klara said they were outside the scope of today’s discussion.  

Bob Newlin asked how many applications might be listed if the “flex authenticator” became the default.  Rob said this would be a function of the number of services that opt to take advantage of it.  Tracy added that this would impact only the applications that opt-in to use this functionality.  Klara added that thus far the effort has been exclusively a technical one, with specific questions about how this would be implemented and marketed to be addressed later.  Robert W. asked if this fits in well enough with the shibboleth model to enable federated intercampus authentication; Klara said it did.

Rob added that the user preference driven model is not the only option; an application can be configured to require a second factor authentication even if a given user did not opt in.  This allows application owners to ensure a higher level of authentication.  

Klara asked if this would address ECAC’s concerns at a conceptual level. Craig agreed that conceptually this would.  He added that one common issue is that people forget their PINs.  He asked how this “PIN reset” process might work.  Klara noted the question and added that the specifics would need to be addressed.  One idea would be to leverage the existing challenge-response functionality.

An ITAC member asked if the PIN was secured solely by the username and password; that is, if username and password were compromised, would the PIN be in jeopardy.  Klara said that at this point, the environment is only a mockup for demonstration purposes.  Rob added that this could mature into a process were the level of assurance an application requires could drive the levels and factors of authentication required.  Klara noted that there are numerous technical solutions that could be implemented but suggested that the usability of the service needed to be weighed as well.

David Jarmul said there would need to be a significant communication and education campaign around this effort.  Furthermore, he suggested that the communication effort might be more costly and daunting than the technical implementation.  

Bob Newlin said that the term “single sign-on” to him indicates authenticating one time and having that authentication provide access to multiple resources.  He asked what the user experience might be for an authenticated user versus a non-authenticated user.  Rob said the shibboleth model has the application specify its minimal authentication level.  Shibboleth would forward authorized credentials if they met the application’s specified level.  If additional authentication levels were required by the application, the user would be prompted to enter that information.  Klara added that even though single sign-on appears to have you “authenticated everywhere,” the reality is that the systems are constantly re-authenticating against signed-on credentials.

Rob said the Security Office is testing phone-factor authentication.  This system uses registered telephone numbers and calls them when you try to access an application. Rob demoed the phone-factor authentication.  Klara said the phone factor authentication is attractive since RSA and other systems are expensive to acquire and implement, but most individuals already have access to a phone.

Alvy L. asked how widespread the concerns ECAC raised are, and if these solutions are overkill.  Craig said that from his perspective this was intended to provide additional authentication for only one application (i.e., Duke@Work). Robert W. suggested that this may become more prevalent with the increase in digitalization.  Terry added that one of the benefits is that this can still be user driven since users may place different levels of value on their information.  

Wayne Miller said his first thought upon hearing about two-factor authentication was about institutional information that already has this in place.  For example, a system where an individual has access to all student information. Conversely, someone said they share their NetID passwords so assistants could access their email.  Wayne said many e-mail solutions have technical solutions (proxies) to this problem.  Terry noted that sharing passwords is a topic for a future session.  

Dave Richardson said the demos showed a quick, low-level way of introducing higher levels of security.  

Michael Ansel asked about the extensibility of the underlying infrastructure to add new authentication mechanisms as they become available.  Rob said that it would be extensible, but that this service is not yet built into Duke’s infrastructure.  Klara and Tracy said that PIN level authentication is something that could be implemented relatively quickly, if that was something that was decided to pursue.  Terry noted that feedback received at ECAC less than six months ago resulted in a relatively quick technical proposal and mock-up.  Terry wondered if the group agreed that Duke@Work would be a viable first candidate as the pilot application.  

Alvy asked what was different about implementing a PIN versus just having the user change their password.  Tracy said this enables users to add additional layers of security.   Terry said that in the Schools of Medicine and Nursing, stricter password aging and history requirements drive password security.  Some discussion ensued about the role of a PIN in addition to the password.  Robert noted that members appear to favor moving favor with a pilot, but he reiterated his earlier concern that a second password is not necessarily a second factor.  He’d like to have other factors as options.  Klara asked if tokens would be a workable solution for customers.  Multiple members suggested the phone solution might be better.

Jim Daigle asked what the status of the Active Directory account and password synchronization effort was since it had been put on hold to address these concerns.  Klara said that NSOE is piloting the sync effort.  In addition, the implementation of the Oracle Identity Management (OIM) solution will be a pre-requisite for the sync, she said.



DukeMail changes to minimize email blacklisting - Mark McCahill

Terry introduced the DukeMail topic as describing an effort to minimize the possibility of Duke University e-mail being blacklisted.  Mark McCahill described the current process by which generally gets blacklisted today.  Generally, a compromised account leads to external forces utilizing Duke’s infrastructure as a spamming force.  Duke accounts are an attractive target because our robust infrastructure and a general trusting of Duke email, until the spamming starts.  Once that occurs, Duke may be blacklisted by mail providers or intermediaries, leading to an inability to send messages Hotmail, Yahoo, and others, he said.

Mark said the team wanted to look at changing the service enough to allow legitimate mail delivery and uphold Duke’s reputation.  He said numerous peers have implemented systems that monitor outgoing mail, flag anomalies, and then take action based on thresholds.  This is not a perfect solution, but it keeps the spam at levels low enough to stay off blacklists.  

Mark described how Duke might use a specific application to re-configure and monitor its gateways.  This process would support whitelists as well, he said.  The philosophical change is that rather than delivering all mail as fast as possible, Duke’s mail infrastructure would deliver reasonable amounts of mail quickly and monitor for “unusual activity” and treat that as a possible security issue.

Robert W. asked about the role and implementation of the whitelists.  Specifically, he asked about the ability to spread out emergency and group messages to avoid systems overload.   Mark said spammers tend to send a few test messages, wait, and then flood the system(s).  Mark said we could modify internal mail to be spread out, but that mass notifications tend to need to require immediate distribution.

Alvy asked about the blacklist thresholds and the probability of spammers gaming the system. Mark said a hopeful outcome of these changes would be to make Duke a less desirable spammer target. Mark said this might be able to be in place in late August.  Tracy added that this would have to be accompanied by a significant communication effort.

An ITAC member asked if this was separate from the effort discussed at a previous ITAC meeting for improving network security on select campus subnets.  Mark said this effort is in addition to that.  Paul Horner said those changes will happen in a few weeks and will then be monitored.  

Terry asked if there was an effort to communicate these change to the student body.  John B. said students will still have the ability to register devices that need to be able to work around the requirements.  Terry said that the implementations will only be successful if coupled with an effective communication plan.  Paul said that he is working with Steve on how to communicate this effort.  Klara said that the student back to school effort is a good time to introduce this.

Michael Ansel asked how students learn about running their own servers or network configuration.  Paul said that those policies do not exist.  Netreg was discussed as a possible location for that type of information.  Terry suggested policies change and that the larger issue may be how to keep people informed.  Klara said there is some work underway to possibly redesign the NetID web authentication page.

Robert W. said it was important to not put ITAC or OIT in the position of judging content.  Paul added that content monitoring was not at all part of the scope.



Microsoft licensing agreement - Klara Jelinkova, Evan Levine

Klara introduced Evan Levine, OIT’s Software License Coordinator.  Klara said they hoped the presentation would be more question and answer based on the communication effort around the recent Microsoft Campus Agreement.  So far the desktop products (Windows and Office) have been made available for download.  OIT has collaborated with DHTS, the School of Nursing, and the School of Medicine to ensure the process and the distribution methods were the same, she said.  In addition, OIT is working with IT Council and Extended Staff to discern how to distribute niche products, such as foreign language Office installations.  Klara said those types of requests should go through departmental IT staff.  OIT continues to work on automating these processes.

Evan said that 300 office downloads and over 100 Vista downloads had taken place over the previous 24 hours. Michael A. asked if students were covered.  Klara confirmed students are covered and described the process for their perpetual coverage.  Evan said this information is covered on the graduating students page on the OIT web site.

Terry asked if family computers would be covered by this agreement.  Rafael said that would not be in compliance with the licensing agreement.  However, home use provisions are available from Microsoft for a nominal fee.

An ITAC member asked about “quasi-Duke” units such as DSCR.  Evan said it’s based on the affiliation.  Rafael said the license is based on FTE numbers Duke provided Microsoft.  If the individual in question is a Duke employee, they are covered; if they are only an affiliate, then they are not.  

Robert W. noted that certain Vista OS versions are not currently available because of some CODEC licensing issues.  Evan said Vista Business and Enterprise are currently available for download.  These machines will get their activation through a KMS OIT is running.  Every installation of Vista Ultimate requires its own key.  

John noted that this is not software that will be owned, but leased.  Should Duke decide to no longer renew its contract, active licenses would continue to work for up to 180 days.  The only exception is for graduating students who will have a perpetual license, said Rafael.

Terry asked if a similar deal might be on the horizon for Apple products.  Klara said Duke has an agreement with Apple for OS pricing.  In addition, Office for the Mac is covered.  Evan noted that OS X enables Windows Upgrade licenses to be run in their virtual space or dual boot space.  Terry asked if OS X would be downloadable.  Evan said Apple may allow the ISO to be downloadable as long as it is not burned.

An ITAC member asked about home usage of MS Office.  Rafael said the license was for any Duke work, independent of the location of the machine.  Robert W. asked if there would be any issues with home machines “calling in”.  Evan said home machines would need to VPN in to Duke.  Rafael advised home users to get the CD because that would have a key that would last forever.

Klara notes that faculty or staff who wish to purchase Office for home use can visit <http://www.microsofthup.com/hupus/home.aspx?culture=en-US> and obtain it for $9.99 on their own. They can request media through this program as well for $12.99. This is a software assurance benefit we have activated via the campus agreement and are already distributing a program code for their use.

Alvy asked what the experience would be of a workstation that had not been re-activated for 180 days.  In addition, he wanted to know if he could force the machine to re-activate through a VPN connection.  Evan said that clients could initiate reactivation. If one is going to be gone for an extended period of time, OIT can provide you with a specific license key.