On Tue, 16 Jul 2002, Tamas TEVESZ wrote:
>
> hi,
>
> this is not neccessarily a strictly exim-related question.
>
> i've been reading various rfcs on smtp and related subjects but can't
> get this thing straight:
>
> when there's (forex.) smtp auth going on, certain parts of the
> dialogue are conducted in base64-encoded form. rfc2045 (page 25) says:
>
> "
> The encoded output stream must be represented in lines of no more
> than 76 characters each. All line breaks or other characters not
> found in Table 1 must be ignored by decoding software. [...]
> "
>
> rfc2554 says:
>
> "
> The BASE64 string may in general be arbitrarily long. Clients
> and servers MUST be able to support challenges and responses
> that are as long as are generated by the authentication
> mechanisms they support, independent of any line length
> limitations the client or server may have in other parts of its
> protocol implementation.
> "
Well, MIME (RFC 2045) can use base 64, and (MIME) may impose a 76
character per line limitation.
SMTP AUTH can use base 64 as well, but it isnt MIME. base 64 itself
doesnt have a 76 character limitation.
Sounds like you are confusing MIME and SMTP.
> and it doesn't talk about any 76-character wraps, but, it indeed talks
> about base64, which in turn seems to require the 76-character wraps
> (at most 76 chars that is; my interpretation is that it can be
> smaller).
>
> i'm not sure how to interpret this; is there something i missed which,
> at least in the smtp dialogue case, says something like "base64
> without the 76-character limit" (i actually seem to remember something
The 76 chracter limit is not set by SMTP, but by MIME.
> like that, but it fades away in distant memory... i think it was wrt
> http authentication headers...); or... or i don't know. i tried to
> feed exim with wrapped ("\r\n") base64 data, and it spits the first
> part back as "invalid base64 data", and invalid command for the rest
> (of course). the code in src/auths/b64decode.c indicates this is very
> much the intended action.
>
> i know i'm kindof stretching the issue to the extremes, as in the case
> of CRAM-anything, longer shared secrets longer than L bytes (as in
> rfc2104) for any given H algorithm are hashed with H and the resulting
> L long hash is used as the shared secret, but if H is, say, rmd160
> (L=20, 40 in hex representation), with even just a moderately long
> username + the hexhash of the shared secret, all these b64-encoded,
> could easily result in a response longer than 76 chars, at which any
> well-behaved base64 encoder should soft-break.
>
> unless, of course, (and i'm quite sure about this) i'm missing
> something very obvious.
>
> could anyone please sched some light in the right direction ?
>
> thanks,
>
>
> --
> [-]
>
>
> --
>
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##
>
>
