headers
Joe Salowey | 1 Mar 2012 06:57
Picon
Favicon

Issue 33: Certificate enrollment

The current tunnel method draft contains TLVs for PKCS#10 and PKCS#7 TLVs.  

The purpose of either of these TLVs is not well described.   I think we need to describe the purpose of these
TLVs better or remove them.  

The PKCS#10 TLV makes a brief reference to the Simple PKI request of CMS (RFC 5272), but does not provide much
more description than that reference.

The PKCS#7 TLV doesn't really describe it usage.  It could be used to carry the enrollment response, or it
could be used to send a root certificate to the peer in the case where an inner method is used to authenticate
the tunnel.  

It doesn't seem that either of these is a complete enough specification.  

Does someone care enough about this functionality to provide better and more complete test for it? 

Thanks,

Joe
Permalink | Reply | 4 comments |
headers
Joe Salowey | 1 Mar 2012 07:29
Picon
Favicon

Re: Issue 33: Certificate enrollment


On Feb 29, 2012, at 10:09 PM, Dan Harkins wrote:

> 
> On Wed, February 29, 2012 9:57 pm, Joe Salowey wrote:
>> The current tunnel method draft contains TLVs for PKCS#10 and PKCS#7 TLVs.
>> 
>> The purpose of either of these TLVs is not well described.   I think we
>> need to describe the purpose of these TLVs better or remove them.
>> 
>> The PKCS#10 TLV makes a brief reference to the Simple PKI request of CMS
>> (RFC 5272), but does not provide much more description than that
>> reference.
>> 
>> The PKCS#7 TLV doesn't really describe it usage.  It could be used to
>> carry the enrollment response, or it could be used to send a root
>> certificate to the peer in the case where an inner method is used to
>> authenticate the tunnel.
>> 
>> It doesn't seem that either of these is a complete enough specification.
>> 
>> Does someone care enough about this functionality to provide better and
>> more complete test for it?
> 
>  I care about this functionality and will be willing to describe
> the syntax of these messages but what test are you talking about?
> 

[Joe] Thanks Dan, I was thinking of walking on hot coals...  Ooops, I meant text.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dan Harkins | 1 Mar 2012 07:09

Re: Issue 33: Certificate enrollment


On Wed, February 29, 2012 9:57 pm, Joe Salowey wrote:
> The current tunnel method draft contains TLVs for PKCS#10 and PKCS#7 TLVs.
>
> The purpose of either of these TLVs is not well described.   I think we
> need to describe the purpose of these TLVs better or remove them.
>
> The PKCS#10 TLV makes a brief reference to the Simple PKI request of CMS
> (RFC 5272), but does not provide much more description than that
> reference.
>
> The PKCS#7 TLV doesn't really describe it usage.  It could be used to
> carry the enrollment response, or it could be used to send a root
> certificate to the peer in the case where an inner method is used to
> authenticate the tunnel.
>
> It doesn't seem that either of these is a complete enough specification.
>
> Does someone care enough about this functionality to provide better and
> more complete test for it?

  I care about this functionality and will be willing to describe
the syntax of these messages but what test are you talking about?

  Dan.
Permalink | Reply | 3 comments |
headers
Sam Hartman | 6 Mar 2012 00:32
Picon
Favicon

New draft on mutual crypto binding problem


Folks, I'd like to draw your attention to a draft we've put together
describing the crypto binding interaction with channel binding and other
peer-focused EAP services that I posted back in January.  Please see
draft-hartman-emu-mutual-crypto-bind-00.txt.

there are a few rough edges. A couple of figures need to be added. we'd
also like to describe where existing tunnel methods  are in terms of
vulnerability to these issues and where inner methods are in terms of
providing keys and EMSKS.
Dacheng zhang has compiled a lot of this data but I didn't get a chance
to integrate it today.

I'd like to thank all those who have helped with this so far  and
welcome any feedback.

We'd like to request time at the EMU session to discuss this attack and
the implications for our ongoing work.
Permalink | Reply | 7 comments |
headers
Alan DeKok | 6 Mar 2012 14:37
Favicon
Gravatar

Call for Agenda items

  Please submit requests for agenda items to the EMU chairs.

  Alan DeKok.
Permalink | Reply | 8 comments |
headers
Dan Harkins | 6 Mar 2012 20:05

Re: Issue 33: Certificate enrollment


  Hi Joe,

  Here are my 4 suggestions to address certificate enrollment:

1. Add New section
------------------

3.9 Certificate Provisioning Within the Tunnel

   Provisioning of a peer's certificate is supported in TEAP by performing
   the Simple PKI Request/Response from [RFC5272] using PKCS#10 and
   PKCS#7 TLVs, respectively. A peer sends the Simple PKI Request using a
   PKCS#10 CertificateRequest encoded into the body of a PKCS#10 TLV (see
   section 4.2.14). The TEAP Server issues a Simple PKI Response using a
   PKCS#7 degenerate "certs-only" message encoded into the body of a PKCS#7
   TLV (see section 4.2.13).

   The Simple PKI Request/Response generation and processing rules of
   [RFC5272] SHALL apply to TEAP, with the exception of error conditions.
   In the event of an error, the TEAP Server SHOULD respond with an Error
   TLV using the most descriptive error code possible; it MAY ignore
   the PKCS#10 request which generated the error.

2. Modify 4.2.4
---------------

Add error codes

     2003 Unsupported Algorithm in CertificateSigning request
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hao Zhou | 7 Mar 2012 19:13
Picon
Favicon

Re: New draft on mutual crypto binding problem

Sam:

This is a well thought and well written draft, it covers a lot of background
and aspect of the attacks and mitigations. However, I have few comments:

1. I don't agree that Mutual crypto-binding is the recommended mitigation
and should be added to TEAP. I actually think proper server authentication
or server policy is better mitigation. Reasons:
A. Mutual crypto-binding required the use of EMSK, not all existing EAP
method generate and export EMSK. It will also break intermediate AAA
servers. More importantly, it would only work for an EAP method that
generates keys. Part of the goal of Tunnel Method is to protect weak
authentication or EAP method, this would not benefits them.
B. The root of the problem is a legitimate NAS acting as something it
shouldn't be. If the peer can detect that from the beginning, that will
prevent further damages such as leaking of credentials, sensitive data etc.
Thus I strong recommend we emphasize on server cert validation and introduce
the concept of authorization to the server authentication. Certain server
can be only used for the services that are authorized. If the peer is
seeking certain services and encounter a server that is not on the
authorized server offering this type of service, despite it is a legit
server for other services, it should refuse to connect to it. It's like you
don't log onto Facebook to do your bank transactions:) I don't think
Standard cert naming is enough, we need some sort of authorization built
into the cert name or a peer side policy, what service the holder can offer.
C. Adding Crypto-binding to TEAP would complicate things, we will need to
try to negotiate that and fall back to the case where inner method doesn't
generate EMSK. And it doesn't protect the methods that doesn't generate
keys.
D. Enforcing server policy would be another good way to go, if server can
(Continue reading)

Permalink | Reply | 5 comments |
headers
Joe Salowey | 9 Mar 2012 05:37
Picon
Favicon

Re: Issue 33: Certificate enrollment

Thanks Dan,

Lets update the draft and have some discussion of it in the Paris meeting.

Cheers,

Joe
On Mar 6, 2012, at 11:05 AM, Dan Harkins wrote:

> 
>  Hi Joe,
> 
>  Here are my 4 suggestions to address certificate enrollment:
> 
> 1. Add New section
> ------------------
> 
> 3.9 Certificate Provisioning Within the Tunnel
> 
>   Provisioning of a peer's certificate is supported in TEAP by performing
>   the Simple PKI Request/Response from [RFC5272] using PKCS#10 and
>   PKCS#7 TLVs, respectively. A peer sends the Simple PKI Request using a
>   PKCS#10 CertificateRequest encoded into the body of a PKCS#10 TLV (see
>   section 4.2.14). The TEAP Server issues a Simple PKI Response using a
>   PKCS#7 degenerate "certs-only" message encoded into the body of a PKCS#7
>   TLV (see section 4.2.13).
> 
>   The Simple PKI Request/Response generation and processing rules of
>   [RFC5272] SHALL apply to TEAP, with the exception of error conditions.
>   In the event of an error, the TEAP Server SHOULD respond with an Error
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Salowey | 9 Mar 2012 06:42
Picon
Favicon

Re: draft-ietf-emu-eap-tunnel-method 7.6: inadequate for interoperable implementation

Hi Sam,

If we added something along the following lines to the document would it be sufficient:

"When performing server certificate validation implementations MUST provide support rules in RFC 5280
for validating certificates against a known trust anchor.  In addition, implementations SHOULD support
matching the realm portion of the client's NAI against a SubjectAltName of type dNSName within the server
certificate.  "

I'm not sure about EKU.  I don't particularly like using the same EKU's as TLS.   If we define a new EKU then
servers will need to get new certs.   Do you think we need EKUs?  

Thanks,

Joe
On Feb 17, 2012, at 2:04 PM, Sam Hartman wrote:

> 
> Hi.
> I'm writing up a draft on mutual crypto binding.
> As such, I happened to glance at section 7.6 on server certificate
> validation.
> 
> The advice there is entirely inadequate for interoperable
> implementation and violates the tunnel method requirements:
> 
> 1) .  There's a SHOULD check the server name, but there are
> no mandatory-to-implement name forms.
> That is, I don't know how to map something the peer is likely to have
> such as the realm in a NAI to something that could be in a certificate.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pascal Urien | 11 Mar 2012 19:22
Picon

Re: Call for Agenda items

Hi All

I would like present the draft-urien-eap-smartcard-22.txt ( http://tools.ietf.org/html/draft-urien-eap-smartcard-22 ) at the next EMU IETF meeting in Paris.

This draft, whose first version was issued in 2002, is an ISO7816 interface for EAP methods such as EAP-SIM, EAP-AKA and EAP-TLS. It has been validated/tested with many most secure microcontrollers supporting the javacard language and associated JVM (i.e. javacards). It comprises three sets of test vectors for EAP-SIM, EAP-AKA and EAP-TLS.

Recent smartphones (Android, RIM, … ) include Secure Elements, usually embedded in NFC controllers that are equipped with javacard JVM, and which are consequently compatible with this draft.

The tested EAP methods implementations need require less than 20KB of nonvolatile memory and 1KB of RAM, these features are compatible with the Secure Elements resources.

Regards

Pascal Urien


2012/3/6 Alan DeKok <aland <at> deployingradius.com>
 Please submit requests for agenda items to the EMU chairs.

 Alan DeKok.
_______________________________________________
Emu mailing list
Emu <at> ietf.org
https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
Emu <at> ietf.org
https://www.ietf.org/mailman/listinfo/emu
Permalink | Reply | 7 comments |

Gmane