prof wrote:

Trước tiên, hoàn toàn đồng ý với alice ở điểm ICV không phải là DS. ) Tuy nhiên, khi viết đoạn này, ý đồ của mình không nhằm so sánh DS và ICV. Mình tuy là kẻ *ngâm cứu* không chuyên về applied crypto. & its related stuffs nhưng cũng may mắn hiểu được sự khác biệt về phạm vi ứng dụng, và về bản chất của DS. Trong phạm vi bài này, mình sử dụng DS với mục đích giúp người đọc hiểu được những lợi điểm do ICV đem lại, kiểu như dùng một thuật ngữ đã quen thuộc để giải thích cho một thuật ngữ mới hơn. Có lẽ chúng ta đều biết DS có khả năng cung cấp tính xác thực (Authentication), tính toàn vẹn (Integrity), và tính chống phủ nhận (Non-repudiation). ICV trong AH Header cũng hội đủ các điều kiện để cung cấp 2 trong 3 khả năng này. Vì vậy, ở một khía cạnh hẹp & trực quan nào đó, ICV mang đặc điểm của DS.

Mình cũng đã từng gặp ở một số tài liệu khác, khi đề cập đến một intemediate device/application/middleware/..., người viết thường mượn thuật ngữ proxy server nhằm mục đích nói lên tính trung gian của đối tượng đang xét, mặc dù nếu khắt khe hơn, thì proxy server không thể là đối tượng mà họ đang bàn. Đó chỉ là một ví dụ khá *thô* về cách dùng thuật ngữ mà thôi. )

Anyway, có lẽ mình đã lạm dụng thuật ngữ DS này nên dẫn đến hiểu lầm. Prof sẽ chỉnh sửa lại đoạn này bằng việc bỏ đi thuật ngữ DS.  

Ồ, alice thật có lỗi khi đã viết ở đó 1 câu bình cộc lốc. Thực sự, các bài viết của prof ở HVA vài năm nay đã chứng tỏ một kiến thức sâu rộng về cryptography và các ứng dụng của nó, còn lối diễn đạt dễ hiểu và phong cách tranh luận khiêm tốn đã thể hiện tính chuyên nghiệp rất cao. Một khi prof. prof tự đánh giá mình là người nghiên cứu "không chuyên" thì alice phải hoảng hốt tự nhận mình là kẻ "tà ma ngoại đạo" thui ) . Nếu được viết lại, alice sẽ viết thế này:

"Sự ví von rất hay, đã làm cho giải thích thêm phần dễ hiểu. Tuy nhiên, nếu viết từ chữ ký trong "nháy nháy" và không mở ngoặc viết thêm phụ đề Anh ngữ digital signature (DS) thì thuật ngữ sẽ không bị "đụng hàng" và tính chất ví von sẽ được thể hiện rõ nét hơn nữa. :! ) "

Khi tính chống phủ nhận (non-repudiability) đã được đề cập, luôn tiện nói thêm, nhóm giao thức IPSEC không có tính chất này. Đó không phải là một thiếu sót. Ngược lại, plausible deniability (tính phủ nhận được?) là cần thiết. Nhờ thế An và Bình có thể liên lạc với nhau mà sau này có thể "cãi bay chối biến" vì không để lại chứng cứ nào về sự liên lạc. Giám định viên tư pháp muốn tìm chứng cứ chống lại An cũng đành phải bó tay ngay cả khi Bình bội bạc với An. )

Plausible deniability là một trong những mối quan tâm khi thiết kế IPSEC và ở một chừng mực nào đó, đã được đảm bảo.

prof wrote:

alice wrote:

Phần NAT màu vàng thứ hai nói về tính tương thích của NAT với IKE, cũng nên nói rõ hơn một chút (nhưng chính alice cũng chưa biết nói thế nào cho rõ ), tránh cho người đọc những thắc mắc kiểu như tại sao khác với nhiều giao thức trên nền TCP/UDP, IKE phải cố định cổng nguồn?. 

Chà, xem ra "người đọc" muốn mở rộng thêm vấn đề về tính tương thích giữa NAT và việc cố định cổng nguồn của IKE đây. Trường hợp này, có lẽ phải mời người tham khảo thêm RFC 3715 để biết chi tiết. ) Phải thừa nhận một điều là còn khá nhiều vấn đề giữa NAT và IPSec mà prof chưa thể nói hết. Bởi vậy, ngay từ đầu, mình chỉ dám đi sâu một chút, vì biết sẽ không đủ sức. Nếu alice hay bạn nào đó có thời gian, các bạn có thể bổ sung thêm những vấn đề mà mình chưa đề cập đến.  

Ớ, RFC 3715 đâu có giải thích tại sao IKE cố định cổng nguồn đâu, chỉ nói ra điều đó thui muh ). Một cách nghiêm túc, RFC này tổng kết 16 điểm không tương thích NAT -- nguyên văn: NA(P)T -- của nhóm giao thức IPSEC, đánh số từ a) đến p), trong đó có 9 điểm đầu tiên thuộc loại thâm căn cố đế (intrinsic). Việc cổng nguồn IKE cố định được prof lấy làm thí dụ, nếu alice hiểu không lầm, là điểm d), chỉ được RFC nêu ra như là một thực tế "ngời ngời như chân lý" thôi. Cho dù đó là thực tế, alice không nghĩ rằng nó hiển nhiên như một yêu cầu chuẩn định (normative).

Đó là điều mà trong bài trước alice đã muốn "nói rõ thêm một chút mà không biết nói thế nào". )

Còn việc mở rộng vấn đề ra một cách rõ ràng và đầy đủ, alice cũng không có nguyện vọng đó. alice biết mình không đủ qualified và mặt khác, nhất trí hoàn toàn với prof, RFC 3175 đã gọn ràng đến mức khó có thể trình bày lại vấn đề cho gọn gàng hơn. Không tương thích IPSEC với NAT là một "tổ kiến lửa" mà việc "chọc" vào nó là không thích đáng trong phạm vi của một bài tut. )