Subject: RE: [Isms] draft agenda for Minneapolis

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 28 Feb 2005 10:03:40 -0800

> -----Original Message-----
> From: Ken Hornstein [mailto:[email-masked]] 
> Sent: Monday, February 28, 2005 8:23 AM
> To: [email-masked]
> Subject: Re: [Isms] draft agenda for Minneapolis 
> 
> >EUSM will use the EAP-TLS protocol defined in RFC2716 as the 
> EAP method 
> >to support authentication systems such as Kerberos,
> >X.509 and local accounts.
> 
> (WG chair hat off)
> 
> Upon reading RFC2716, I've discovered that it only mentions 
> Kerberos (and Public Key) once.  Specifically, it says:
> 
> Through the use of EAP, support for a number of 
> authentication schemes may be added, including smart cards, 
> Kerberos, Public Key, One Time Passwords, and others. To date 
> however, EAP methods such as [6] have focussed on 
> authenticating a client to a server.
> 
> It doesn't really mention how this will happen.  If you look 
> at the EAP document (RFC3748), it doesn't explain how you 
> could use Kerberos or PKI with EAP either (I looked at PEAP, 
> but that seems to focus only on protecting the EAP exchange, 
> rather than doing certificate validation as part of the EAP 
> authentication).
> 
> Maybe I'm missing something, but it seems like there's a bit 
> of handwaving here.
> 

[Joe] It is true that EAP (RFC 3748) does not specify authentication
methods, it specifies a way to carry out an authentication exchange.  It
is also true that there are few EAP Methods that are currently defined
as RFCs.  However, RFC 2716 specifies EAP-TLS which uses TLS
ciphersuites for authentication.  TLS ciphersuites provide mutual
authentication of peers using various types of credentials.  The EAP-TLS
specification is no worse than the TLS specification a specifying how
PKI can be used in any particular environment, but I agree that there
needs to be some additional specification around how certificates and
PKI can be used with respect to SNMPv3, but my feeling is that TLS
ciphersuites give us as good a good basic mechanism for PKI support.
All of the EAP-TLS implementations I know support X.509 public key
certificates for mutual authentication.  

RFC 2712 describes Kerberos ciphersuites for TLS.  I agree that here as
well additional specification around how Kerberos is used specific to
SNMP is needed (for example what principal name is used), but I also
feel that this provides a good base.  Perhaps there are better ways to
implement a Kerberos EAP mechanism, the Kitten working group is making
enhancements to GSSAPI which could make a GSSAPI EAP mechanism easier to
implement.  This is something the working group can discuss.

In any case I think it would be advantageous to use an existing
authentication frameworks (such as EAP and TLS) where possible and if
required extend these frameworks with new methods that could be used
with other solutions. The requirements for SNMP should not be radically
different  than other uses for EAP so it is the intent that enhancements
made for SNMP should be applicable to the mainstream of EAP development.

Joe

> --Ken
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 28 Feb 2005 15:37:33 -0800

> From: Salowey, Joe 
> Sent: Monday, February 28, 2005 10:04 AM
> To: Ken Hornstein; [email-masked]
> Subject: RE: [Isms] draft agenda for Minneapolis 
> 
>  
> 
> Kerberos 
> > (and Public Key) once.  Specifically, it says:
> > 
> authentication schemes 
> > may be added, including smart cards, Kerberos, Public Key, One Time 
> > Passwords, and others. To date however, EAP methods such as 
> [6] have 
> > focussed on authenticating a client to a server.
> > 
> > It doesn't really mention how this will happen.  If you look at the 
> > EAP document (RFC3748), it doesn't explain how you could 
> use Kerberos 
> > or PKI with EAP either (I looked at PEAP, but that seems to 
> focus only 
> > on protecting the EAP exchange, rather than doing certificate 
> > validation as part of the EAP authentication).
> > 
> > Maybe I'm missing something, but it seems like there's a bit of 
> > handwaving here.
> > 
> 
> [Joe] It is true that EAP (RFC 3748) does not specify 
> authentication methods, it specifies a way to carry out an 
> authentication exchange.  It is also true that there are few 
> EAP Methods that are currently defined as RFCs.  However, RFC 
> 2716 specifies EAP-TLS which uses TLS ciphersuites for 
> authentication.  TLS ciphersuites provide mutual 
> authentication of peers using various types of credentials.  
> The EAP-TLS specification is no worse than the TLS 
> specification a specifying how PKI can be used in any 
> particular environment, but I agree that there needs to be 
> some additional specification around how certificates and PKI 
> can be used with respect to SNMPv3, but my feeling is that 
> TLS ciphersuites give us as good a good basic mechanism for 
> PKI support.
> All of the EAP-TLS implementations I know support X.509 
> public key certificates for mutual authentication.  
> 
> RFC 2712 describes Kerberos ciphersuites for TLS.  I agree 
> that here as well additional specification around how 
> Kerberos is used specific to SNMP is needed (for example what 
> principal name is used), but I also feel that this provides a 
> good base.  Perhaps there are better ways to implement a 
> Kerberos EAP mechanism, the Kitten working group is making 
> enhancements to GSSAPI which could make a GSSAPI EAP 
> mechanism easier to implement.  This is something the working 
> group can discuss.
> 
> In any case I think it would be advantageous to use an 
> existing authentication frameworks (such as EAP and TLS) 
> where possible and if required extend these frameworks with 
> new methods that could be used with other solutions. 

[Joe] I just wanted to clarify what I meant by "TLS framework"  since I
received some offline questions on it.  TLS provides a framework for
authenticated key exchange which can be extended to support different
credential types by defining different ciphersuites.  I was not
referring to the use of TLS for anything other than authenticated key
exchange, this is consistent with the current usage of EAP-TLS. 

>The 
> requirements for SNMP should not be radically different  than 
> other uses for EAP so it is the intent that enhancements made 
> for SNMP should be applicable to the mainstream of EAP development.
> 
> 
> Joe
> 
> 
> 
> > --Ken
> >