Re: [Emu] TEAP Comments

2013-01-29 Thread Hao Zhou (hzhou)
Jim:

Thanks for the detailed review comments. Response inline below. Will try
to submit a new rev with these changes soon.


>
>On 11/15/12 3:24 PM, "Jim Schaad"  wrote:
>
>>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.
>[HZ] We will add a flag bit in sub-type to indicate presence of EMSK
>and/or MSK MAC.
>>
>>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)
>[HZ] Will add a sentence to clarify.
>
>>
>>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
>[HZ] Will add that.
>
>>
>>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.
>[HZ] Looks ok. Will add.
>
>>
>>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.
[HZ] Sounds reasonable. Will add an error TLV with new error code for the
signaling mechanism.
>>
>>Jim
>>
>>
>>> -Original Message-
>>> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
>>> Jim Schaad
>>> Sent: Wednesday, November 07, 2012 4:48 PM
>>> To: emu@ietf.org
>>> Subject: [Emu] TEAP Comments
>>> 
>>> 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
>>> 
>>> 
>>> ___
>>> Emu mailing list
>>> Emu@ietf.org
>>> https://www.ietf.org/mailman/listinfo/emu
>>
>>___
>>Emu mailing list
>>Emu@ietf.org
>>https://www.ietf.org/mailman/listinfo/emu
>

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


Re: [Emu] TEAP Comments

2012-11-15 Thread Jim Schaad
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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
> Jim Schaad
> Sent: Wednesday, November 07, 2012 4:48 PM
> To: emu@ietf.org
> Subject: [Emu] TEAP Comments
> 
> 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
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

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


[Emu] TEAP Comments

2012-11-07 Thread Jim Schaad
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


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