RE: [Nea] Revised draft NEA charter

["Narayanan, Vidya" <vidyan at qualcomm.com>]

Steve,

> 
> Vidya,
> 
> Sorry I mischaracterized your comments as coming from a 
> service provider perspective. Whatever the perspective, I 
> appreciate them.
> 

No worries. 

> > I don't see how NEA can detect compromised endpoints even 
> with trusted 
> > hardware - with trusted hardware storing the attributes, it 
> just means 
> > that a compromised device may not be able to tweak the 
> attributes (I'm 
> > not even totally convinced of this at the moment, but let's 
> say that).
> 
> This is a big discussion. I'll start a separate thread for it.
> 

I'm slowly catching up with that thread. I'll respond to this point on
that thread. 

> > > Re-validation after an IP address has been assigned would 
> typically 
> > > (but not necessarily) be done via a layer 3 protocol, 
> thus avoiding 
> > > the need to disrupt network access during the re-validation.
> > > 
> > 
> > Having said this, what is the result of posture validation? 
> > The analogy
> > I am able to make in my mind is something like a virus or 
> application 
> > patch update/notification process - is that what is being 
> > standardized?
> 
> The results of posture validation can include remediation or 
> restrictions on network access. For validation some time 
> after network access has already been granted, restricting 
> network access may use RADIUS CoA message, for example. 
> Remediation is the process of fixing problems with the 
> endpoint, manually or automatically.
> It can include installing patches or updates to the operating 
> system, applications, or virus definitions. That's common. It 
> can also include changes to configuration settings on the 
> endpoint (like enabling the firewall) and other things like 
> doing a virus scan.
> 
> The current NEA charter does not propose to standardize what 
> happens after posture validation. It's focused on the 
> protocols for posture validation itself.
> 

Right, I do understand this. In order to appreciate the charter and the
work, I was, however, trying to piece the big picture together. 

> > The charter says "It will also include requirements for the 
> protocol 
> > transporting PA, PB: the Posture Transport protocol (PT). Specific 
> > requirements for an EAP instantiation of PT will be identified." - 
> > this seems to imply that the primary protocol intended to 
> carry PA and 
> > PB is an EAP method. Or, am I missing something?
> 
> That darn sentence has been causing all sorts of trouble! ;-) 
> The NEA charter is supposed to be transport independent. But 
> people are definitely interested in EAP. It's a very popular 
> transport, supported by all the major NAC architectures but 
> in incompatible ways. So it was suggested that we should 
> include specific requirements for EAP so that the EMU group 
> or someone else could work on a standard transport for NEA if 
> they want to at some later time.
> 
> Maybe the sentence should be changed to something like this:
> 
> Specific requirements for an EAP instantiation of PT will be 
> identified in case standardization in that area is desired.
> However, standardization of an EAP instantiation is not in 
> scope for the NEA working group.
> 

The wording itself is okay, but I am trying to see what the deployment
model is likely to be, given what NEA is standardizing and what it may
ask other WGs in the IETF to standardize. Right now, I'm only seeing EAP
as the alluded solution and that in general concerns me. 

Regards,
Vidya

> > > The requirements document includes a discussion of device 
> compromise 
> > > in its security considerations section (8.1).
> > > Maybe we will need to include something about this in the 
> charter. 
> > > What do others think?
> > 
> > I believe the charter should clarify this. 
> 
> We seem to have consensus on this. Let's add a paragraph on 
> this topic to the charter once we agree on what it should say. ;-)
> 
> > > As for de-coupling NEA from network access, that's 
> already part of 
> > > the plan (as described above). Maybe we need to make the charter 
> > > clearer on this point.
> > > 
> > 
> > Aside from the confusions mentioned above, when it is 
> de-coupled from 
> > network access, it is not clear to me as to where the transport 
> > protocol is going to be specified.
> 
> There are other working groups better suited for such work.
> For instance, an EAP method should probably go through the 
> EAP or EMU working groups. I don't think our charter should 
> call out work for other working groups. That got us into 
> trouble last time. I hope the text on this that I proposed 
> above will help clarify it.
> 
> Thanks,
> 
> Steve
> 

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea