Subject: Re: [Emu] AD review of draft-ietf-emu-eap-tunnel-method

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 10 Jul 2013 16:53:32 +0000

On Jun 28, 2013, at 9:40 AM, Sean Turner <[email-masked]> wrote:

> I trimmed this down to the ones that weren't resolved.  Let me know how those two items end getting resolved.
> 
>>> 7) s3.2.2: Paque opaque MUST NOT????  What about the other MUSTs in this
>>> section?
>> [HZ] Not quite understand what you mean. Please explain.
> 
> Yeah this one got sent out early ;)  Sorry about that.
> 
> What I meant to write was please add some text about why there are MUST NOTs.  If it's just a MUST NOT to make things easier then you'll get push back later but if there's a reason for the MUST NOTs and you include it now it'll smooth the way later.
> 

[Joe] OK

>>> 8) s3.8.2: Couple of questions:
>>> 
>>> 8.1) How is the pkcs7/10 encoded; is it encapsulated in an media-type
>>> (i.e., does it include the content-type, etc headers)?  The PKCS#10 is
>>> covered in 4.2.17, but what about the PKCS#7.
>> [HZ] We will look into this and get back you.
> 
> ack

[Joe]   We will add text that the PKCS#10 and PKCS#7 use binary DER encoding .  

> 
>>> 8.5) Need some text about verifying the returned certificate back to an
>>> authorized TA.  Don't want the client to willy-nilly accept the returned
>>>  certificate.
>> [HZ] Good suggestion. Do you have any text to suggest or from EST?
> 
> I was thinking simply "The peer MUST verify the returned certificate to an authorized Trust Anchor."

[Joe] We have some text about this in 4.2.16, is that sufficient?

> 
>>> 8.6) Are the CRLs for the issuing CA returned as part of the certs-only
>>> message or will the client use the CRLs from the TLS handshake?  Should
>>> we have some kind of guidance about if the client is going to do this
>>> that it SHOULD pull the CRLs/OCSP responses for the CA?
>> [HZ] We are looking into and will get back to you.
> 
> 

[Joe]  I think the current text in 4.2.16 about the TEAP server returning CRLs is incorrect.  CRLs for the CA certificates is not done within TEAP, they may be retrieved after TEAP has completed.     

Separately, the TEAP server certificate may be checked against OCSP during the handshake, but this does not necessarily have anything to do with the CA certificate or the certificates described in this section. 

> 
>>> 24) s3.7: Assume this throws off an error?  Is there some kind of catch
>>> all sentence someplace that I missed that says all MUST NOTs result in
>>> an error being thrown?
>> [HZ] What is "this?"
> 
> This bit:
> 
> The L
> flag is set to indicate the presence of the four-octet TLS Message
> Length field, and MUST be set for the first fragment of a fragmented
> TLS message or set of messages.  It MUST NOT be present for any other
> message.
> 
> It's back to providing text about the reason for the MUST NOT.
> 

[Joe] Error handling is described in section 3.6.x  

> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Jul 2013 22:57:50 -0400

>>>>> "Sean" == Sean Turner <[email-masked]> writes:

    >>> 8.5) Need some text about verifying the returned certificate
    >>> back to an authorized TA.  Don't want the client to willy-nilly
    >>> accept the returned certificate.

    Sean> I was thinking simply "The peer MUST verify the returned
    Sean> certificate to an authorized Trust Anchor."

Sorry for a late comment, but I cannot understand why this is desirable.
The peer has already authenticated the TEAP server.
Why does the cert need to chain back to a TA?
Requiring cert validation when it's not needed seems undesirable.
I think this should be a MAY rather than MUST.
Or am I confused and there's some attack I am missing?

---

From: Sean Turner <[email-masked]>
Date: Thu, 11 Jul 2013 07:35:29 -0400

> [Joe] We have some text about this in 4.2.16, is that sufficient?

After further review it seems fine.

> Separately, the TEAP server certificate may be checked against OCSP during the handshake, but this does not necessarily have anything to do with the CA certificate or the certificates described in…

roger that

ack

looking forward to the next version.

spt

---

From: Sean Turner <[email-masked]>
Date: Thu, 11 Jul 2013 08:01:54 -0400

> Or am I confused and there's some attack I am missing?

The certificate here is one that is new provisioned.  If a client is 
given a certificate that it will use to sign and or encrypt and it 
cannot validate that back to an installed TA, then it seems like maybe 
there's something wrong?  At least, that's where I was going.  After 
re-reading it, I think they're good with the text they've got.

spt

spt

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Jul 2013 08:43:59 -0400

Sean> On 7/10/13 10:57 PM, Sam Hartman wrote:
    >> >>> back to an authorized TA.  Don't want the client to
    >> willy-nilly >>> accept the returned certificate.  >> [HZ] Good
    >> suggestion. Do you have any text to suggest or from >> EST?
    >> 
    >> 
    >> Sorry for a late comment, but I cannot understand why this is
    >> desirable.  The peer has already authenticated the TEAP server.
    >> Why does the cert need to chain back to a TA?  Requiring cert
    >> validation when it's not needed seems undesirable.  I think this
    >> should be a MAY rather than MUST.  Or am I confused and there's
    >> some attack I am missing?

    Sean> The certificate here is one that is new provisioned.  If a
    Sean> client is given a certificate that it will use to sign and or
    Sean> encrypt and it cannot validate that back to an installed TA,
    Sean> then it seems like maybe there's something wrong?  At least,
    Sean> that's where I was going.  After re-reading it, I think
    Sean> they're good with the text they've got.

OK.  If I'm remembering correctly this is a cert I might use for EAP
authentication; I guess I could use it for other purposes although is
somewhat unspecified.

If you require TA validation, then you require that I keep my clients in
sync with my EAP server's idea of what trust anchors it trusts.  It may
want to use an online CA that's less trusted than the offline CA I use
for EAP server certificates, etc, so there's no reason to assume that
just because I can validate the server cert I can validate the newly
issued client certificate.

If I'm using EAP because it's a convenient way to do authenticated cert
provisioning, then I may well have some other mechanism like AD group
policy to push out trust anchors.

However if I'm using EAP because this is a new machine that is first
appearing on the network, I probably don't have a good opportunity to
push out new trust anchors.  Although, hmm, I had to either push out a
fingerprint of the EAP server cert or push out a trust anchor for that.

So, I don't think TA validation is necessary, but given that you need to
provision for the server cert, I don't think it creates significant
deployment problems either.
So, I don't really care one way or the other.