Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method-05 - Set #2

2013-03-11 Thread Joseph Salowey (jsalowey) 
HI Jim,

Thanks for bringing this up.   I think it might be better to address this in a 
separate document since I think it can have more general applicability than 
TEAP.   I'll add this to the TEAP discussion in Orlando.  Comments inline below:
On Mar 4, 2013, at 6:13 PM, Jim Schaad 
i...@augustcellars.commailto:i...@augustcellars.com wrote:

I have been doing my best not to send this message but it has finally slipped 
out.

I keep wondering if we need to do something much more explicit in terms of both 
identifying and purposing the certificates that are being used for this method.

Question #1 – Do we expect that the client certificates would only be used for 
this purpose and not for general purpose TLS client authentication?  I would be 
shocked if this was not true for the server certificates.  If so does this mean 
that we should define an EKU for the purpose of doing EAP Tunnel Method (allow 
it to be used for all of the previous and future versions thus being generic)?


[Joe] Both cases exist in deployments today, there are cases where server and 
client certificates are used for both HTTPS and EAP.  It is more common on the 
client side.  I believe EAP-TLS specifies the same EKUs as TLS for HTTP.   I've 
always found it a bit strange, but I don't think ti has presented a serious 
deployment issue.   I think it would be reasonable to define a new EKU, but I'd 
like to understand how it would or wouldn't work with what is out there.



Question #2 – Do we want to try and solve the question Sam has raised about 
naming of entities in certificates.  This would mean defining a new OtherName 
extension to PKIX for the purpose of placing NAIs into certificates.  This 
would allow for an NAI of the form “@realm” to be placed in a server 
certificate to define that it is the EAP server for the realm.  This does 
assume that there will not be two different servers which are disjoint 
servicing the same realm but that would be a very unusual case.

[Joe] Being able to identify the realm and NAI would be good.  For the realm 
does this need to be distinct from DNS name?


Jim

___
Emu mailing list
Emu@ietf.orgmailto:Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Comments on draft-ietf-emu-eap-tunnel-method-05 - Set #2

2013-03-04 Thread Jim Schaad 
I have been doing my best not to send this message but it has finally
slipped out.

 

I keep wondering if we need to do something much more explicit in terms of
both identifying and purposing the certificates that are being used for this
method.

 

Question #1 - Do we expect that the client certificates would only be used
for this purpose and not for general purpose TLS client authentication?  I
would be shocked if this was not true for the server certificates.  If so
does this mean that we should define an EKU for the purpose of doing EAP
Tunnel Method (allow it to be used for all of the previous and future
versions thus being generic)?

 

Question #2 - Do we want to try and solve the question Sam has raised about
naming of entities in certificates.  This would mean defining a new
OtherName extension to PKIX for the purpose of placing NAIs into
certificates.  This would allow for an NAI of the form @realm to be placed
in a server certificate to define that it is the EAP server for the realm.
This does assume that there will not be two different servers which are
disjoint servicing the same realm but that would be a very unusual case.

 

Jim

 

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu