draft-zhu-kerb-enctype-nego-04 changes from 03

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

draft-zhu-kerb-enctype-nego-04 changes from 03

Kenneth G Raeburn
Larry has submitted version -04 of this document.  It contains some  
changes he made based on some comments I made.  A quick summary:

The enctype list no longer needs to contain all the supported  
enctypes.  Specifically, enctypes less desirable to the client than  
the session key enctype, and any local-use (negative) enctype numbers  
not known to be supported by the server, are left out.

The session key enctype may be excluded from the enctype list at the  
client's choice; if it is excluded, this tells the server that it  
MUST NOT use that enctype (or, in other words, if it sends a subkey,  
and it supports this extension, it must use a different enctype,  
chosen from the list).  If the session key enctype is included, it  
goes at the end of the list.

New reference to X.680 as well as X.690 for ASN.1 DER.  Fixed  
reference to X.690.  Fixed spelling of Sam's last name.

Ken

Reply | Threaded
Open this post in threaded view
|

Re: draft-zhu-kerb-enctype-nego-04 changes from 03

Jeffrey Hutzelman


On Monday, October 24, 2005 05:06:10 PM -0400 Ken Raeburn <[hidden email]>
wrote:

> Larry has submitted version -04 of this document.  It contains some
> changes he made based on some comments I made.  A quick summary:
>
> The enctype list no longer needs to contain all the supported  enctypes.
> Specifically, enctypes less desirable to the client than  the session key
> enctype, and any local-use (negative) enctype numbers  not known to be
> supported by the server, are left out.
>
> The session key enctype may be excluded from the enctype list at the
> client's choice; if it is excluded, this tells the server that it  MUST
> NOT use that enctype (or, in other words, if it sends a subkey,  and it
> supports this extension, it must use a different enctype,  chosen from
> the list).  If the session key enctype is included, it  goes at the end
> of the list.
>
> New reference to X.680 as well as X.690 for ASN.1 DER.  Fixed  reference
> to X.690.  Fixed spelling of Sam's last name.

We already did a last call on this document, but the changes decsribed
above are substantive in nature.  In addition, we have an outstanding
issue related to how enctype negotiation interacts with RFC4121 and
prot_ready, which is on our agenda to discuss in Vancouver.  Once that
is resolved, we should be able to send this document on to the IESG.
In the meantime, comments on the above change are welcome.

-- Jeff

Reply | Threaded
Open this post in threaded view
|

Re: draft-zhu-kerb-enctype-nego-04 changes from 03

Chaskiel Grundman-3
In reply to this post by Kenneth G Raeburn
--On Monday, October 24, 2005 17:06:10 -0400 Ken Raeburn <[hidden email]>
wrote:

> The session key enctype may be excluded from the enctype list at the
> client's choice; if it is excluded, this tells the server that it  MUST
> NOT use that enctype (or, in other words, if it sends a subkey,  and it
> supports this extension, it must use a different enctype,  chosen from
> the list).  If the session key enctype is included, it  goes at the end
> of the list.

Unless some future specification makes this extension mandatory, the MUST
seems silly. since there is no extension-specific data in the AP_REP, the
client cannot tell if the server supports the extension unless the server
changes the subkey type. (and so from a protocol point of view, there is no
difference between the server not supporting the extension and ignoring
this MUST)

Reply | Threaded
Open this post in threaded view
|

RE: draft-zhu-kerb-enctype-nego-04 changes from 03

Larry Zhu
In reply to this post by Kenneth G Raeburn
You are correct that the server can always choose to ignore the
extension.

 

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Chaskiel M
Grundman
Sent: Monday, October 24, 2005 2:57 PM
To: [hidden email]
Subject: Re: draft-zhu-kerb-enctype-nego-04 changes from 03

--On Monday, October 24, 2005 17:06:10 -0400 Ken Raeburn
<[hidden email]>
wrote:

> The session key enctype may be excluded from the enctype list at the
> client's choice; if it is excluded, this tells the server that it
MUST
> NOT use that enctype (or, in other words, if it sends a subkey,  and
it
> supports this extension, it must use a different enctype,  chosen from
> the list).  If the session key enctype is included, it  goes at the
end
> of the list.

Unless some future specification makes this extension mandatory, the
MUST
seems silly. since there is no extension-specific data in the AP_REP,
the
client cannot tell if the server supports the extension unless the
server
changes the subkey type. (and so from a protocol point of view, there is
no
difference between the server not supporting the extension and ignoring
this MUST)

Reply | Threaded
Open this post in threaded view
|

Re: draft-zhu-kerb-enctype-nego-04 changes from 03

Kenneth G Raeburn
In reply to this post by Chaskiel Grundman-3
On Oct 24, 2005, at 17:57, Chaskiel M Grundman wrote:
> Unless some future specification makes this extension mandatory,  
> the MUST seems silly. since there is no extension-specific data in  
> the AP_REP, the client cannot tell if the server supports the  
> extension unless the server changes the subkey type. (and so from a  
> protocol point of view, there is no difference between the server  
> not supporting the extension and ignoring this MUST)

Right.  I mentioned this when talking with Larry.  I think the idea  
is, "this enctype from the KDC is too weak for exchanging lots of  
data, so if you don't come back with a different enctype, I'm just  
going to close the connection".  I'd prefer a SHOULD here, with an  
explanation of that case.

Ken

Reply | Threaded
Open this post in threaded view
|

RE: draft-zhu-kerb-enctype-nego-04 changes from 03

Larry Zhu
In reply to this post by Kenneth G Raeburn
If the server understands this extension, then it MUST honor the
request. I think this way we can get more consistent behavior and the
key word MUST simplifies implementations. I would prefer the "MUST" over
the "SHOULD" here, and at the same time I acknowledge that it is not
enforceable.

-- Larry

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Ken Raeburn
Sent: Monday, October 24, 2005 4:21 PM
To: Chaskiel M Grundman
Cc: [hidden email]
Subject: Re: draft-zhu-kerb-enctype-nego-04 changes from 03

On Oct 24, 2005, at 17:57, Chaskiel M Grundman wrote:
> Unless some future specification makes this extension mandatory,  
> the MUST seems silly. since there is no extension-specific data in  
> the AP_REP, the client cannot tell if the server supports the  
> extension unless the server changes the subkey type. (and so from a  
> protocol point of view, there is no difference between the server  
> not supporting the extension and ignoring this MUST)

Right.  I mentioned this when talking with Larry.  I think the idea  
is, "this enctype from the KDC is too weak for exchanging lots of  
data, so if you don't come back with a different enctype, I'm just  
going to close the connection".  I'd prefer a SHOULD here, with an  
explanation of that case.

Ken

Reply | Threaded
Open this post in threaded view
|

Re: draft-zhu-kerb-enctype-nego-04 changes from 03

Nicolas Williams
In reply to this post by Chaskiel Grundman-3
On Mon, Oct 24, 2005 at 05:57:09PM -0400, Chaskiel M Grundman wrote:

> --On Monday, October 24, 2005 17:06:10 -0400 Ken Raeburn <[hidden email]>
> wrote:
>
> >The session key enctype may be excluded from the enctype list at the
> >client's choice; if it is excluded, this tells the server that it  MUST
> >NOT use that enctype (or, in other words, if it sends a subkey,  and it
> >supports this extension, it must use a different enctype,  chosen from
> >the list).  If the session key enctype is included, it  goes at the end
> >of the list.
>
> Unless some future specification makes this extension mandatory, the MUST
> seems silly. since there is no extension-specific data in the AP_REP, the
> client cannot tell if the server supports the extension unless the server
> changes the subkey type. (and so from a protocol point of view, there is no
> difference between the server not supporting the extension and ignoring
> this MUST)

Since the client knows all the enctypes it supports it should suffice
for the client to say "pick one of these or I'll go away" -- there' no
need to say "do not pick one of these or I go away" and, besides, that
would cause problems if the server supported enctypes that the client
didn't ("the server picked an enctype I don't know" -> oops).

Reply | Threaded
Open this post in threaded view
|

Re: draft-zhu-kerb-enctype-nego-04 changes from 03

Sam Hartman-5
In reply to this post by Larry Zhu
>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[hidden email]> writes:

    Liqiang(Larry)> If the server understands this extension, then it
    Liqiang(Larry)> MUST honor the request. I think this way we can
    Liqiang(Larry)> get more consistent behavior and the key word MUST
    Liqiang(Larry)> simplifies implementations. I would prefer the
    Liqiang(Larry)> "MUST" over the "SHOULD" here, and at the same
    Liqiang(Larry)> time I acknowledge that it is not enforceable.

I tend to agree with Larry that a must is reasonable.  I'm less
convinced that a must is a good idea in this instance but I don't
think it is harmful.

I'll try to discuss with larry and Ken and see why the must is there.