Security & Trust Meeting 2010-07-15

Notes from NHIN Direct Security & Trust Meeting

Date: July 15, 2010
Time: 2pm-3pm
Attendees: Nick Radov, Fred Trotter, David McCallie, Adrian Gropper, John Moehrke, Mike Berry, Sean Nolan, Arien Malec, Brian Behlendorf, Uvinie Hettiaratchy, Deborah Lafky, Pete Palmer, Mike Davis
Actions from this week:

#	Date	Action	Status	Owner	Due Date
37	7/15/10	Update description of encryption options	Open	Sean Nolan	7/22/10
38	7/15/10	Reach out to Dixie when appropriate amount of documentation is done.	Open	Arien Malec / David McCallie	7/30/10

Actions from last week:

#	Date	Action	Status	Owner	Due Date
33	7/8/10	Clarify what happens in a wrapped model	Open	Arien Malec	7/8/10
34	7/8/10	Create table of encryption options, nothing PHI exposure risks	Open	Sean Nolan	7/15/10
35	7/8/10	Review John Moehrke’s risk assessment model and Sean Nolan’s model on the wiki	Open	WG	7/15/10
36	7/8/10	Take John’s risk assessment of end to end S/MIME model and see which risks are applicable to Sean’s model.	Open	WG	7/15/10

Agenda:
1. Pete Palmer has agreed to give us a condensed overview of the recently released National Strategy for Trusted Identities in Cyberspace document.

2. Pick up the discussion of header encryption where we left off. As discussed last week, a more structured review of the topic is posted here: Framing the Header Encryption Issue ... Go around the room and see if we can get agreement on any of the four options for the content header issue.

3. Proposal for workgroup next steps and interactions with the Tiger team. My original thoughts below, but will hand to Arien for recommendations and then discussion.

Request an live (ideally f2f) meeting with the Tiger team to present our guidance to the implementation team. Ask is for:

• Confirmation that we are moving in a direction aligned with the likely outcomes of policy work --- e.g., understanding the policy work will continue, is it reasonable to expect that we are 90% in the ballpark so that implementations will have minimal churn as final policy guidance emerges?
• Any KNOWN issues that we are not covering that we need to address.

Notes
Arien Malec

• Let’s start with a review of the National Strategy document.

Pete Palmer

• Deborah Lafky also on the call, so she can provide more detail.
• Discussions on identity frameworks and governance.
• Focused on technical side and protocols.
• Please review this document.
• Motivation for it is similar to NHIN Direct.
• Took work done by government and SDOs and coordinate together for ecosystem for digital identities.
• Nothing new, but tying it together to identify clear strategy for public-private partnership.
• If look at document, there are a few comments and there was a big brother concern.
• They want to provide a strategy and means for private sector to operate with government.
• Health IT is recognized in use cases. There’s one for e-prescribing and patient consent.
• Wanted to bring attention to this group so could provide comments.
• White House really trying to get identity provider world involved.

David McCallie

• How does this relate to Cantera initiative?

Pete Palmer

• After 9/11, 800-63 work and others in researching standards to implement identity access program was for all 17 million government employees and contractors
• They quickly recognized that they could go so far. That’s how EPA started.
• It was designed to be harmonized so we could have pieces in place to go forward with a strategy.
• Cantera has worked in parallel and has standards that are harmonized with federal government standards.
  • Now rolling out assessment program
  • Now if identity provider you can get in line and receive your assessment against various assurance levels.
  • These are in parallel to assurance levels and procedures and polices in 800-63.

David McCallie

• Does it boil down to interoperability guarantees and approach to getting policy interoperability?

Pete Palmer

• Most of that is done, so now working to get it rolling.
• Federal government is making a big attempt to provide services.

David McCallie

• Timetable?

Deborah Lafky

• We just had first meeting in implementation workgroup yesterday. Looking at 6 month timeframe, but working to put something out by October.
• Draft form for comment before end of calendar year.

Mike Davis

• Participated in some of the activity.

Fred Trotter

• We’ve been asked lots of times and it’s come up again and again, does this mean now the answer is this initiative is the way we’re going?

Pete Palmer

• I’d love to see that be the case.

Brian Behlendorf

• With NHIN Direct, we have infrastructure that allows for implementation group to do whatever it wants to do. We have a framework to accommodate whatever implementation plan they come up with because can point to multiple trust groups.
• We’ve allowed for a lot of possible outcomes.
• This workgroup will help make that a practical reality by showing how it works and helping the public get a mental model for how a digital identity works.

Sean Nolan

• Hope people will spend a little bit of time with this.

Fred Trotter

• Would like to be involved with identity taskforce. Any way I can be put in touch with them?

Deborah Lafky

• This is a federal work group.

Sean Nolan

• Next item is to continue discussion from last week.
• Issue 2 – we have a few options we could make recommendations for.
• In brief, the issue that arose is that the S/MIME spec allows for two models for encryption. One encrypts header and one does not. There is a risk of PHI being in content headers. There is also an issue of routing, which has a different dynamic and we can discuss that separately.
• The method which encrypts all the headers has downside in that it is not currently supported by clients today.
• Four options:
  • Specify that content headers will not be encrypted in message body.
  • Require that headers always be encrypted, but off the shelf client challenge.
  • Completely punt this issue and say that you have to support full S/MIME spec and both models.
  • Hybrid – NHIN Direct software rewrite does full header encryption but we’ll leave open possibility that messages may pass through software with unencrypted headers so sender and receiver does that.

Arien Malec

• Clarification on Option 4 - If you’re taking responsibility for encryption, you’re also responsible for what is inside and outside encrypted portion.

Sean Nolan

• Passing through encryption. That’s the four options.
• I’m willing to accept either option.

Round the Room on four encryption options

Nick Radov	No comment
Fred Trotter	No comment
David McCallie	Question for Arien – what would stop us from doing full encryption and removing it at the receiver? Is the issue what keys you would use? Arien Malec - If you’re doing that, you’re holding the private keys for the sender or the receiver. If you designated that the HISP was a pure router, then likely you’re not providing a private key. I like the hybrid model.
Adrian Gropper	No comment
John Moehrke	· Complex issue. I did post a discussion thread on this. One of problems that I have is that this wrapped with policy decision based on sender’s policies and how they expect things to happen. What we need to focus on is what is the capability that needs to be there so that the interoperability between the sender and receiver is well defined. We also have to recognize that the sender system is totally decoupled from receiving system. The only reliance is that in that middle piece, they are using a common specification. More specifically, there is a step option – we could accept this as a critical problem and create isolation of all HISPs. Agree more with Arien, that we define the specification and it’s up to sender while they’re validating consent that they have proper controls in place to do the right thing. Even in case of Sean’s proposal of using a MIME attachment which is the encapsulated NHIN Direct email message, the outer body of that message is still exposed. · I opt for simple S/MIME and we don’t specify.
Mike Berry	· I read John’s discussion post and agree with everything. The case where this issue comes up is when user is using general purpose email application. At same time, if we go with option number 1, we lose some of the adoption because lose ability to use off the shelf email client. · I am a supporter of Arien’s option – hybrid option number 4. The problem with the full encryption option is that it takes away from spirit of going with SMTP in the first place.
Pete Palmer	No comment.
Mike Davis	No comment. From discussion, maybe someone could make assurance that it’s not a technical issue, but putting a policy decision placed down to end user that forces them to make decisions that they may not be prepared to make. We don’t want to make end user responsible for making policy decisions based on technology limitations. Sean Nolan - That is fair. We’re not doing that. That could be an individual but only if individual chose to be a HISP.
Brian Behlendorf	I want to make sure we are understanding risk appropriately. HISP to HISP exchange is always encrypted. The exposure risk is endpoint to endpoint from sending or receiving HISP. Both parties are trusted at least by one endpoint. Receiving HISP always knows the To, but unless we say that the HISP is going to hide the From, they will know the from. We’re really worried about subject line. I worry that if we feel HISPs are organizations that cannot be trusted, then we do need to do a significant amount of engineering. We have always considered them as trusted. John Moehrke - Presumption that we would not be exposing TLS. Sean Nolan – I split this into one and two. We said HISP can take on role of BA. We have not had discussions on when this would not be the case. That could free up potential for innovation. If routing information becomes considered PHI, that’s a different discussion. We can expect policy people will think about them separately. John Moehrke – Wanted to point out that there are two architectures on table. My architecture does not hide risks and HISP is not a trusted entity. Brian Behlendorf – Part of win is to be able to use off the shelf technology.
Arien Malec	Clearly I agree with my proposal. In this discussion about HISP, it’s been a consistent theme from policy side that we should not make an assumption that the HISP must be trusted. We should design technology for non-trusted HISP to do bare minimum without requiring it to have access to more PHI. If look at early discussions, we did have assumption of end to end SMTP where you could use plain email routing system. I think it’s an interesting discussion. Just to restate proposal – if taking on end to end problem, full problem managing certificates, encryption processes, etc., you’re taking on a lot. Additional step of also understanding what they are and not encrypting. We can make this simpler by Agent and proxy modes. That’s a model where just like HTTP proxy, you can have an SMTP proxy that applies agent model locally and sends on to its chosen SMTP.

David McCallie
· Analogous bridge program for XDR.
John Moehrke
· Need to separate sender system from receiver system. Support that with single specification that speaks about what’s going on in the middle and less time on either side.
David McCallie
· In agreement. My concern was management of PKI issues.
John Moehrke
· There are services today that do secure messaging for you. If we choose S/MIME and download Eudora, or use secure mail service, or open source agent.
Sean Nolan
· When real policies come out, we’ll have more clarity. The action on that is to put together a brief statement that talks about our recommendation to the implementation groups and what the agent should do when they’re creating their systems.
· I’ll write it up.
John Moehrke
· Suggest that we specify that there are two alternatives.
o 1) simple S/MIME implemented with common email with identified risks.
o 2) Wrapped model that addresses these risks. Then we place the requirement on any solution that they declare they support one or the other.
Sean Nolan
· Since both techniques are in S/MIME standard, need to support both.
John Moehrke
· When tell them implement both, they can mitigate accidents by code. Not clear as to why they support second one if they can forbid mistakes from happening if writing the code themselves.
Mike Berry
· Technical implementation point – it’s possible that when we get into technical implementation, at library level there may not be support for doing a full encryption in a MIME attachment, as there is library support in doing it the regular way.
Sean Nolan
· In any case, my expectation has been that we’re asking the groups to come back and talk to us about it.
· Next few months will give dose of reality.
· Ask Arien for perspective on how best to establish a relationship in ongoing way to interact with Tiger team. To give ideas and give live feedback.
Arien Malec
· The Tiger team and Policy committee expressed desire to stay focused on pure policy not tied to technology.
· They want to create generalized mechanisms for data handling and consent and recognize areas where you may not have to do the full thing.
· Most useful would be to touch base with Dixie and Wes.
· I think the Tiger team would appreciate that over technical details.
David McCallie
· I think it’s a good idea to go back to Standards Committee – Halamka, Dixie, etc. and say here’s what we came up with and threat analysis and present our questions. Ask for a repeat review.
· If issues that come out of that process that need to go to Tiger Team, then use them as the channel.
· I’m sensitive that Paul Egerman and Deven McGraw don’t want to revisit NHIN Direct.
Sean Nolan
· Should we do nothing then?
Arien Malec
· I agree with David, but we shouldn’t do nothing. I think Dixie would be first stop.
· Will reach out to her, and David will too.
David McCallie
· When we have stuff ready, and not too soon.

•