| From: | Ken Raeburn <raeburn@MIT.EDU> |
| To: | krb5-bugs@MIT.EDU |
| Subject: | enctype negotiation - etype list |
| Date: | Mon, 12 Jan 2009 18:58:23 -0500 |
The current enctype negotiation code on the trunk has a funny way of
coming up with the enctype list to send.
The RFC says that if the session key is in the list, it should be at
the end.
The current code looks up the enctype list, which is ordered by
preference, and scans it for the session key type. If it finds it, it
*swaps* it with the entry at the end of the list. So if the session
key type was first on the list, it's now last, and you're telling the
application server that the enctype you'd really like to use is the
one that was originally last in your preference order.
It probably should truncate the list after the session key type, if
it's found. And, just for kicks, check and see if the session key
type is first on the list and skip enctype negotiation altogether if
it is, since we can't get a more-preferred enctype in that case.
Ken
coming up with the enctype list to send.
The RFC says that if the session key is in the list, it should be at
the end.
The current code looks up the enctype list, which is ordered by
preference, and scans it for the session key type. If it finds it, it
*swaps* it with the entry at the end of the list. So if the session
key type was first on the list, it's now last, and you're telling the
application server that the enctype you'd really like to use is the
one that was originally last in your preference order.
It probably should truncate the list after the session key type, if
it's found. And, just for kicks, check and see if the session key
type is first on the list and skip enctype negotiation altogether if
it is, since we can't get a more-preferred enctype in that case.
Ken