Subject: [Emu] TEAP Comments

From: "Jim Schaad" <[email-masked]>
Date: Wed, 7 Nov 2012 19:48:14 -0500

I just wanted to make sure that the mail list had at least the basics of
what I mentioned in the f2f today

1.  The document does not appear to have an indicator that the EMSK was or
was not used to generate a confirmation value.  I have not done a final
check that this is true but I did try and find it a couple of times

2.  The flags on the outer packet need to be defined a bit better.
   a)  is the S bit set only on the first fragment of the first message or
on all fragments of the first message
   b)  are the two length bits set only on the first message in  a fragment
sequence or can they be on any of the messages in a fragment sequence (but
the values must then be the same in all fragment messages)
   c)  Can the O bit be set only in the first piece of a fragment, or could
it be in the last one without being in any previous one
   d)  Should the L bit never be set on a non-fragmented message since it is
redundant

3.  There needs to be a signaling mechanism when running inner EAP messages
to say that
  a) that this is a reliable transport and therefore there should be
no-retries
  b) If a packet is dropped on the floor by somebody, then some type of
signaling mechanism needs to be created to signal this to the other party.
Also there should be text saying that re-sending the message does not
necessarily make sense as the packet would probably just be re-dropped again
  c) There needs to be some type of policy on the server for what to do for
either failing or continuing a validation - for example should a new EAP
method be tried in this case.

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 15 Nov 2012 12:24:05 -0800

Expanding on the issues so that you have full descriptions of the problem
from the last message

1.  When either an EMSK or MSK is not present in the Crypto-Binding TLV,
there is no way to indicate this.  At the f2f it was said that this was
going to be by setting it to all zeros.  If this is the case, then it does
need to be noted that there is a 1 in 2^n chance that it will signal the
wrong thing leading to an error in binding being generated.  It might be
better to steal bits from the Sub-Type octet instead.

2.  I find that I have probably not correctly understood when the S bit is
set.   I have been setting the S bit on all fragments (but not fragment
responses) of the original Start request and Start response.  I have since
found text that says it is only sent from the server to the peer.  It would
be nice to have the one direction comment in the description of the flags as
well (section 4.1)

3.  I would like to have the description of the L bit in section 4.1
expanded to state the following:
  - It MUST be present for the first fragment of a fragmented message
  - It MUST NOT be present for any other message

The first can be found in section 3.7 (if you hunt) but the second is not
stated anywhere

4.  I would like to have the description of the O bit in section 4.1
expanded to state the following:
 - It MUST be present only in the initial request and response messages.
 - If the initial message is fragmented, then it MUST be present only on the
first fragment.

5.  I don't think point 3 below needs expansion, but I may be too close to
it.  If you disagree please let me know.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jim Schaad
> Sent: Wednesday, November 07, 2012 4:48 PM
> To: [email-masked]
> Subject: [Emu] TEAP Comments
> 
what I
> mentioned in the f2f today
> 
check
> that this is true but I did try and find it a couple of times
> 
on all
> fragments of the first message
> sequence or can they be on any of the messages in a fragment sequence
> (but the values must then be the same in all fragment messages)
>    c)  Can the O bit be set only in the first piece of a fragment, or
could it be in
> the last one without being in any previous one
> 3.  There needs to be a signaling mechanism when running inner EAP
> messages to say that
no-retries
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu